一、一致性设计

约定俗成的，方法的第一个参数往往预留给context.Context类型参数使用，以便接受上下文变量，特别是service层的方法。强制性地将context作为方法第一个参数的好处是，可以形成很好的上下文传递规范、链路跟踪也更容易打通，这也是绝大部分项目的默认设计方式。例如：

二、易用性设计

goframe框架统一的组件设计中并没有强制性将context.Context类型参数作为第一个参数传递，而是从易用性的角度出发（有时也是由于代码的历史原因），采用链式设计方式，将context上下文变量通过Ctx链式操作方法可选择性地输入。这么设计的优点是组件上下文注入灵活、易用性较好，缺点是难以形成上下文传递的编码规范。举几个例子：

1、日志Logging操作示例

2、数据库ORM操作示例

3、Redis操作示例

三、业务如何设计

对于业务开发而言，有几点比较重要的因素必须得优先考虑：

• 统一编码规范的重要性要高于设计灵活性
• 对微服务项目开发而言：链路跟踪是必要的

因此建议采用一致性的上下文设计方式。

此外，该编码规范也很容易通过CI工具检查，并推进规范落地实施。

四、组件如何设计

业务组件开发而言，如果涉及到可能的上下文注入，设计时需要考虑以下几点：

• 是否微服务相关组件，那么会涉及到链路跟踪，编码规范重要性高于灵活性
• 是否核心的基础组件，例如：日志管理、消息队列、数据库操作等，往往需要支持上下文录入
• 是否是业务相关组件，例如通用业务逻辑的封装组件，那么往往需要强制上下文录入
• 非业务组件，并且不是核心组件，往往灵活性要求会高于统一编码规范

Content Menu