go中goroutine无法被直接kill，必须通过协作式退出：使用context.context或done channel通知退出，并在所有阻塞点监听信号，配合waitgroup确保真正终止。
goroutine 无法被直接 kill，必须靠协作式退出
Go 没有 kill goroutine 这种操作，强行终止会破坏运行时状态（比如正在持有 mutex、写 channel、执行 defer）。唯一安全的方式是让 goroutine 自己感知到“该停了”，然后干净收尾。核心不是“杀”，而是“通知+响应”。
常见错误是只发信号不等响应，比如往 done channel 发一个值就以为结束了，但目标 goroutine 可能还没读到、或正在阻塞 IO 中根本没机会检查——结果协程实际还在跑，资源持续泄漏。
- 永远用
context.Context或带缓冲的donechannel 作为退出信号源 - goroutine 内部必须在所有可能阻塞点（
select、time.Sleep、net.Conn.Read）监听退出信号 - 启动 goroutine 的代码需调用
sync.WaitGroup.Done()或接收其完成通知，否则无法确认是否真正退出
用 context.WithCancel 是最通用且可嵌套的退出方案
context.WithCancel 不仅提供单次取消能力，还天然支持父子上下文传播，适合多层 goroutine 协同退出。它比裸 channel 更健壮，因为 ctx.Done() 返回的 channel 是只读且不可重复关闭的，避免了多次 close 引发 panic。
典型陷阱：把 ctx 当参数传进去，但在 goroutine 内部没在 select 中监听 ctx.Done()；或者监听了，却在 default 分支里做轮询，导致 CPU 空转。
- 必须在每个可能长时间运行的分支前加
case - 对阻塞系统调用（如
http.Get、net.Conn.Read），优先选用支持Context的版本（如http.Client.Do带 ctx） - 不要在 goroutine 外部反复调用
cancel()—— 第二次调用会 panic，应确保只触发一次
channel 关闭后仍读取会立即返回零值，不能当作退出信号
很多人误以为关闭 done channel 后，在 goroutine 里 select 到 就算收到信号。其实关闭 channel 后，<code> 会立刻返回对应类型的零值（如 <code>struct{} 零值是空 struct），而不会阻塞——这导致 goroutine 可能“假退出”，尤其当逻辑依赖 channel 是否关闭而非是否收到值时。
正确做法是用带缓冲的 done channel（容量为 1），发送一个值表示退出，并在 goroutine 中明确判断是否收到该值；或更推荐统一走 context，避免手写 channel 状态管理。
- 别用
close(done)作为通知机制，除非你真需要“关闭即退出”语义且能保证 goroutine 已进入监听循环 - 如果坚持用 channel，务必在发送后同步等待 goroutine 结束（例如用
sync.WaitGroup） - 切忌在多个 goroutine 中并发 close 同一个 channel —— panic: close of closed channel
超时退出要小心 select default 分支导致的忙等
用 time.After 或 time.Timer 实现超时控制时，若配合 select + default，很容易写出每毫秒都空转的 goroutine。这不是优雅退出，是制造负载。
真正可控的超时退出，应该让 goroutine 在阻塞点（如网络读、channel 接收）本身支持超时，或使用 context.WithTimeout 并统一监听 ctx.Done()。
-
select中不要写default:来“非阻塞检查”，除非你确定后续有 sleep 或其他节流措施 - 用
time.AfterFunc触发 cancel 更危险——它不保证 goroutine 已响应，只是发信号 - 超时后若 goroutine 仍在运行，应记录日志并检查是否遗漏了某些阻塞路径未监听 ctx
select 分支或一个 defer 里的阻塞操作，goroutine 就可能永远卡住。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
