命令模式封装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 中只读使用。
立即学习“go语言免费学习笔记（深入）”；
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——一旦出现一个“临时绕过”，后续就会有十个。 
