17370845950

命令模式封装HTTP请求更可控，因其将请求逻辑（重试、超时等）与业务意图解耦，通过可组合装饰器、统一错误分类（ErrType）、合理装饰器顺序（WithTimeout→WithRetry→...）及无共享状态的命令实例，提升可测性、可维护性与并发安全性。

为什么用命令模式封装 HTTP 请求比直接调用 http.Do 更可控

因为请求逻辑（如重试、超时、鉴权、日志）和业务意图（如“创建订单”“查询库存”）被硬编码耦合时，一旦某类请求要加熔断或降级，就得改十几处 http.Do 调用——而命令模式把每次请求抽象成可组合、可装饰、可统一拦截的 Command 实例。

• 每个请求行为封装为独立结构体，实现统一的 Execute() 接口，便于单元测试模拟
• 中间件式装饰器（如 WithRetry、WithTimeout）可复用在任意命令上，不侵入业务逻辑
• 命令实例天然携带上下文（context.Context）、参数、预期错误类型，避免全局配置污染

Command 接口设计必须包含 context.Context 和明确错误分类

如果接口只定义 Execute() error，就无法区分网络超时、服务端 503、还是参数校验失败——这会让上层重试策略盲目生效。实际封装中，应让执行方法返回具体错误类型，并允许调用方按需判断。

type Command interface {
    Execute(ctx context.Context) (Response, error)
}

type Response struct {
    StatusCode int
    Body       []byte
    ErrType    ErrorType // 自定义：NetError / BizError / ParseError
}

• ErrType 字段比 errors.Is(err, xxx) 更轻量，避免反复 fmt.Errorf("wrap: %w", err)
• 所有装饰器（如重试）只对 ErrType == NetError 生效，对 BizError 直接透出
• HTTP 客户端构建应由命令内部完成，不暴露 *http.Client 给外部

装饰器链顺序影响重试与超时的实际行为

比如 WithTimeout(5s) 包裹 WithRetry(3)，会导致每次重试都受 5 秒限制；反过来，若 WithRetry 在外层，则整个重试过程最多耗时 5 秒——后者更符合“最大等待时间”的语义预期。

• 推荐装饰器顺序：WithTimeout → WithRetry → WithCircuitBreaker → 命令本体
• 每个装饰器只处理自己关心的错误类型，不吞掉下游返回的 Response.ErrType
• 避免在装饰器里做阻塞操作（如同步日志写磁盘），否则会拖慢整个链路

命令实例不应持有共享状态，但可安全携带请求参数

常见误写是把 url 或 token 存在全局变量或单例中，导致并发请求相互覆盖。正确做法是让每个命令实例在创建时接收不可变参数，并在 Execute 中只读使用。

type CreateUserCommand struct {
    baseURL string
    user    UserInput
    client  *http.Client // 可复用，但必须是线程安全的（如默认 http.DefaultClient）
}

func (c *CreateUserCommand) Execute(ctx context.Context) (Response, error) {
    req, _ := http.NewRequestWithContext(ctx, "POST", c.baseURL+"/users", bytes.NewReader(c.user.Payload()))
    resp, err := c.client.Do(req)
    // ...
}

• 不要在命令里修改 c.user 字段，防止并发调用时数据竞争
• 敏感字段（如 token）建议通过 context.WithValue 传入，而非结构体字段
• 命令构造函数应做必要校验（如 baseURL 非空），避免 Execute 运行时 panic

命令模式真正难的不是定义接口，而是约束团队不绕过它去直调 http.Do——一旦出现一个“临时绕过”，后续就会有十个。