命令队列应使用 chan *struct 而非 interface{}，结构体需含 ID、超时、重试等上下文；停止时结合 context 取消、WaitGroup 与超时兜底；重试策略内置于 Task，避免统一中间件；并发消费需调优 GOMAXPROCS 并谨慎绑定 OS 线程。
命令队列的核心是 chan + struct 组合，不是用接口模拟“命令模式”
Go 没有传统 OOP 的抽象类或接口多态调度机制，硬套 Java 风格的 Command 接口 + execute() 方法，反而增加无谓的类型断言和反射开销。真实高吞吐场景下，应直接用带字段的结构体 + 通道传递，把“命令”当作数据而非行为载体。
-
chan类型必须是具体结构体指针（如chan *Task），避免复制大对象；切忌用chan interface{} - 每个命令结构体应包含必要上下文：ID、超时时间、重试次数、原始参数（建议用
json.RawMessage或map[string]any延迟解析） - 启动一个 goroutine 消费通道，内部用
select控制退出与超时，不要用for range死循环阻塞
type Task struct {
ID string `json:"id"`
Payload json.RawMessage `json:"payload"`
Timeout time.Duration `json:"timeout"`
Retries int `json:"retries"`
CreatedAt time.Time `json:"created_at"`
}
<p>func NewTaskQueue() (chan <em>Task, func()) {
q := make(chan </em>Task, 1024)
done := make(chan struct{})
go func() {
for {
select {
case task := <-q:
if task == nil {
continue
}
ctx, cancel := context.WithTimeout(context.Background(), task.Timeout)
// 执行逻辑（例如调用 handler.Handle(ctx, task.Payload)）
cancel()
case <-done:
return
}
}
}()
return q, func() { close(done) }
}如何安全地停止队列并等待正在执行的任务完成
直接关闭 chan 会导致未处理任务丢失，而粗暴用 sync.WaitGroup 计数又容易因 panic 或阻塞导致 wait 永不返回。正确做法是结合 context 取消信号 + 手动计数 + 超时兜底。
- 消费者 goroutine 内部维护一个
sync.WaitGroup，每开始执行一个任务就wg.Add(1)，完成后wg.Done() - 停止函数先关闭输入通道，再发送取消信号给所有活跃 context，最后
wg.Wait()等待，但必须加time.AfterFunc超时强制退出，防止卡死 - 禁止在
defer wg.Done()外部做耗时操作（如写日志、发 HTTP），否则会拖慢整个 shutdown 流程
重试与错误分类必须由命令结构体自身携带策略，而非统一中间件
不同命令对失败的容忍度差异极大：支付回调失败要立即重试，而日志上报失败可直接丢弃。把重试逻辑提到队列层（如“所有命令统一重试 3 次”）会破坏语义边界，也难以调试。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 在
Task结构体中嵌入RetryPolicy字段，例如：MaxRetries int、Backoff time.Duration、RetryOn []string（指定需重试的错误码） - 执行函数返回
error后，由消费者判断是否满足重试条件：若需重试，修改task.Retries++并重新 send 到队列；否则记录错误并丢弃 - 避免用
errors.Is(err, xxx)做泛化判断——不同 handler 返回的 error 类型不一致，应约定返回自定义 error 类型（如*TemporaryError）并实现IsTemporary() bool方法
并发消费多个命令队列时，注意 runtime.GOMAXPROCS 和 OS 线程绑定
当业务需要同时运行支付队列、通知队列、同步队列等多个独立通道时，若每个都起 10 个 goroutine 消费，可能因调度抖动导致延迟毛刺。这不是通道问题，而是 Go 运行时与操作系统线程交互的细节被忽略。
立即学习“go语言免费学习笔记（深入）”；
- 默认
GOMAXPROCS是 CPU 核心数，但高 IO 场景下建议设为runtime.NumCPU() * 2，避免 goroutine 频繁抢占 M（OS 线程） - 对延迟敏感的队列（如实时风控指令），可用
runtime.LockOSThread()将其 goroutine 绑定到特定 P，减少上下文切换；但必须成对使用runtime.UnlockOSThread()，否则泄漏线程 - 监控指标不能只看
goroutines数量，更要观察go_gc_cycles_automatic_gc_cycles_total和go_sched_park_expires_total，它们更能反映调度压力
真正难的不是把命令塞进 channel，而是让每个 Task 自己说清楚：“我该什么时候重试”“我失败了算不算事故”“我执行完要不要通知谁”。这些语义信息一旦散落在 handler 里，队列就退化成了裸管道。
