命令模式在Go中本质是接口抽象，即定义Command接口并让业务操作实现它，核心在于封装请求与执行逻辑分离，通过依赖注入和command runner实现解耦与可测试性。
命令模式在 Go 中的本质是接口抽象，不是继承或框架
Go 没有类和继承，所谓“命令模式”落地就是定义一个统一的 Command 接口，让各类业务操作都实现它。关键不在“模式名字”，而在是否真把请求封装（如参数、上下文）和执行逻辑（Execute()）拆开了。
常见错误是把 Execute() 写成直接调用 service 层函数，导致 handler 仍需 import 具体业务模块，耦合没解开。
- 真正解耦：handler 只依赖
Command接口，不 import 任何业务文件 - 命令实例应在应用启动时构造并注入，而非在 handler 里 new 出来（否则又引入具体类型依赖）
- 命令对象应持有最小必要依赖（如
*sql.DB或 repository interface），避免传入整个 service
如何设计可测试、可替换的 Command 接口
接口粒度决定解耦深度。太粗（如一个 Run()）难复用；太细（每个字段一个方法）增加维护成本。推荐按“一次完整业务动作”建模，例如：
type CreateUserCommand struct {
Name string
Email string
Repo UserRepository // 依赖抽象，非具体实现
}
func (c *CreateUserCommand) Execute(ctx context.Context) error {
if c.Name == "" {
return errors.New("name required")
}
return c.Repo.Create(ctx, User{Name: c.Name, Email: c.Email})
}
注意点：
立即学习“go语言免费学习笔记（深入）”；
-
Execute()接收context.Context，便于超时、取消、trace 注入 - 所有外部依赖（DB、HTTP client、cache）必须通过字段注入，禁止全局变量或 init 时硬编码
- 不要在命令里做日志埋点或 metrics 上报——这些属于横切关注点，应由 command runner 统一包装
使用 command runner 统一处理前置/后置逻辑
真正实现“请求与执行分离”的关键环节，是把校验、日志、重试、事务等逻辑从命令内部剥离，交给 runner 管理：
type CommandRunner struct {
logger *zap.Logger
}
func (r *CommandRunner) Execute(ctx context.Context, cmd Command) error {
r.logger.Info("command start", zap.String("cmd", fmt.Sprintf("%T", cmd)))
defer r.logger.Info("command end", zap.String("cmd", fmt.Sprintf("%T", cmd)))
if err := cmd.Validate(); err != nil {
return err
}
return cmd.Execute(ctx)
}
这样，业务命令只需专注“做什么”，runner 负责“怎么做、何时做、出错怎么办”。典型陷阱：
- 在 runner 里对不同命令类型做 switch 判断——说明命令接口职责不单一，应回归接口抽象
- runner 直接调用
tx.Commit()——事务应由命令自己控制（如接收sql.Tx参数），runner 不该感知 DB 细节 - 把 validation 逻辑写进 runner 的通用校验函数——会导致校验规则无法随命令演进，应让每个命令实现自己的
Validate()
HTTP handler 如何零耦合调用命令
handler 唯一需要做的，是解析请求、构造命令实例、交给 runner。它不应知道命令内部怎么执行，也不该 import 任何 domain/service 包：
func CreateUserHandler(runner *CommandRunner, repo UserRepository) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
var req struct {
Name string `json:"name"`
Email string `json:"email"`
}
if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
http.Error(w, "bad request", http.StatusBadRequest)
return
}
cmd := &CreateUserCommand{
Name: req.Name,
Email: req.Email,
Repo: repo, // 依赖注入，但 handler 不 import repo 实现
}
if err := runner.Execute(r.Context(), cmd); err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}
w.WriteHeader(http.StatusCreated)
}
}
重点在于：CreateUserCommand 类型定义和 UserRepository 接口必须放在 shared 或 domain 包中，handler 和 repo 实现各自 import 这个包，彼此不直连。
最容易被忽略的是命令生命周期管理——命令对象应是无状态的（stateless），每次请求新建；若误将数据库连接池、缓存 client 等长生命周期资源塞进命令字段，会导致并发问题或资源泄漏。
