goroutine panic 默认静默终止协程而不传播：需在每个并发函数入口用 defer+recover 转为可收集错误；channel 关闭责任唯一，须由主 goroutine 统一关闭；context.WithTimeout 需配合主动检查 ctx.Done() 才能真正终止任务；ants 等协程池 Submit 返回 error 不代表任务未执行，仍需内部 recover 和 ctx 控制。
goroutine 中 panic 会直接终止协程，不传播到主 goroutine
Go 的协程是“隔离”的：一个 goroutine 内部 panic，若没被 recover 捕获，它就静默退出，不会中断其他协程，也不会让主程序崩溃——但你也就彻底丢失了这个错误。
常见错误现象：go doTask() 执行失败，控制台没报错、返回值也没异常，任务像“消失”了一样；查日志发现 panic 被 runtime 吞掉，只留下一句 panic: xxx (PC=0x...) 在 stderr，且无堆栈上下文。
- 必须在每个并发执行的函数入口加
defer+recover，把 panic 转成可收集的错误 - 别依赖
log.Fatal或os.Exit：它们会干掉整个进程，协程池就废了 - 如果用第三方协程池（如
ants），注意它默认不捕获 panic，需手动 wrap 任务函数
用 channel 汇总结果时，别漏关 send 端或漏收 close
典型场景：启动 N 个 goroutine 并发处理任务，通过一个 chan Result 收集结果。结果汇总逻辑卡住、程序 hang 住，90% 是 channel 关闭和接收逻辑没对齐。
常见错误现象：range 遍历结果 channel 一直阻塞；或部分结果永远收不到；或 panic: send on closed channel。
立即学习“go语言免费学习笔记（深入）”；
- 关闭 channel 的责任必须唯一：一般由“所有任务启动完毕 + 全部完成”后的一次性 goroutine 来关，不是每个 worker 自己关
- worker 发送前务必检查 channel 是否已关闭（可用
select+default防止阻塞） - 如果任务可能提前失败（比如 context 被 cancel），要确保错误路径也走统一的“完成通知”机制，否则关闭 channel 的时机无法判断
context.WithTimeout 和 recover 结合才能真正控住超时任务
只用 context.WithTimeout 不代表任务会自动停止——它只是给任务传了个信号；任务本身得主动检查 ctx.Done() 并退出，否则 goroutine 还在跑，协程池资源被占着，错误也汇总不上来。
常见错误现象：设了 5s 超时，但某个任务实际跑了 30s，结果 channel 还没收到它的返回或错误；或者它最终 panic 了，但 panic 被 recover 后塞进结果 channel，时间戳却显示“超时后才返回”。
- 每个 worker 函数开头就要
select监听ctx.Done()，并在退出前把ctx.Err()当作错误返回 -
recover捕获的 panic 应该和ctx.Err()统一处理：都转成Result{Err: err}，避免类型分散 - 不要在 defer 里做耗时操作（比如写日志到网络），它可能在超时后才执行，拖慢整体退出
ants.Pool 的 Submit 返回 error，但不代表任务没执行
用 ants 这类协程池时，pool.Submit(task) 返回非 nil error，只说明“提交失败”，比如池已关闭、任务队列满；但它**不保证任务一定没运行**——有可能刚入队就被执行了，然后 panic，但你根本没机会拿到结果。
常见错误现象：看到 submit failed: pool is closed 就以为万事大吉，结果后台还有几个 goroutine 在默默跑、泄露、甚至改了共享状态。
- 提交前先检查
pool.IsClosed()，比靠Submit返回 error 更可靠 - 哪怕
Submit成功，也要按前面说的，在 task 内部做recover+ctx检查，不能假设“提交成功 = 安全执行” - 池关闭后，建议等
pool.Release()返回（它会阻塞直到所有任务结束），再继续后续清理逻辑
协程池里最麻烦的从来不是怎么发任务，而是怎么确认“每一个任务，无论成功、失败、超时、panic，都留下了可追溯的痕迹”。漏掉任意一种路径，汇总逻辑就会出现空洞。
