Go任务队列中传回调函数不panic的正确方式是：必须显式定义函数类型（如type TaskCallback func(interface{}, error)），注册时判空if cb != nil，闭包捕获变量需注意地址引用，回调中I/O操作须用任务入队时绑定的context副本，坚持双参数签名以区分成功与失败。
回调函数在 Go 任务队列里怎么传才不 panic？
Go 没有原生 callback 类型语法，直接传函数容易因类型不匹配或 nil 值触发 panic: invalid memory address。必须显式定义函数类型，并确保调用前判空。
- 定义统一回调签名：
type TaskCallback func(result interface{}, err error) - 注册时用
if cb != nil显式检查，别依赖 defer 或 recover 拦截 - 回调里禁止直接操作共享状态（如全局 map），应通过 channel 或 mutex 同步
- 如果回调需访问外部变量，注意闭包捕获的是变量地址而非值——循环中传
i要写成func(i int) { ... }(i)
为什么用 goroutine + channel 实现队列比直接 go f() 更可控？
裸 go task() 容易失控：无并发限制、无错误传播路径、无法等待完成。channel 是天然的背压和协调载体。
- 用带缓冲的
chan *Task（比如make(chan *Task, 100)）防止生产者阻塞 - 工作协程从 channel 取任务后，立即执行并调用回调，不要把回调也扔进另一个 goroutine——除非明确需要解耦耗时回调逻辑
- 关闭 channel 前必须确保所有已入队任务被消费，否则会漏掉最后几个
select未命中 - 别用
range ch配合close(ch)做消费者退出——任务队列通常长期运行，关 channel 是终止信号，不是自然结束
回调里调用网络请求或数据库操作，怎么避免上下文超时失效？
回调执行时机不可控，若原始 context 已 cancel，子 goroutine 中再用它发起 http 请求会立刻返回 context canceled 错误。
- 任务入队时，应把有效 context 的副本（
ctx, cancel := context.WithTimeout(parentCtx, 30*time.Second)）存入*Task结构体 - 回调函数内部要使用该副本 context，而不是外层闭包捕获的原始 ctx
- 如果回调本身不涉及 I/O，只是更新内存状态，可忽略 context；但只要调用
http.Client.Do或db.QueryContext，就必须传对应 ctx - 别在回调里调用
cancel()——那是任务启动时的事，回调只负责响应结果
如何让回调能区分成功/失败，又不破坏调用方的错误处理习惯？
Go 的 error 返回是约定俗成的契约。回调签名若只传 result，调用方无法判断是成功还是异常，容易把 nil result 当成正常空值处理。
立即学习“go语言免费学习笔记（深入）”；
- 坚持双参数回调：
func(interface{}, error)，error 为 nil 表示成功 - 任务执行出错时，回调的
err必须是非 nil 的具体错误（如fmt.Errorf("timeout")），不能传nil或空字符串 - 如果业务需要更细粒度状态（如 “部分成功”），应在
result结构体里加字段，而不是滥用 error - 测试回调逻辑时，用
assert.NotNil(t, err)和assert.Nil(t, err)分开断言，别只检查result != nil
