close(ch)不等于安全取消，因其仅通知channel关闭而无语义、不清理资源、无法区分取消原因；context.context的done()才提供带超时、错误、统一调度的可靠取消机制。
用 close(ch) 做取消广播是可行的，但仅限于极简、单次、无上下文的场景；高并发、需资源清理、带超时或跨层级协作时，必须用 context.Context 的 Done()，否则极易漏通知、卡 goroutine 或 panic。
为什么 close(ch) 不等于“安全取消”
关闭 channel 确实能唤醒所有阻塞接收者，但它只传递一个信号：「这个 channel 没数据了」。它不携带任何语义——不知道是超时、出错、还是主动停止；无法区分「正常结束」和「被取消」；更不会自动清理数据库连接、HTTP 客户端或文件句柄。
- 多个 goroutine 同时收到
ok == false，但没人知道该不该释放资源 - 如果某个 worker 正在执行耗时 I/O（如
http.Get），close(done)完全不影响它，它仍会跑完才检查 channel - 你无法在关闭后继续往
workCh发任务，否则可能 panic：send to closed channel
context.WithCancel 才是高并发取消的唯一可靠入口
它把取消信号、超时控制、截止时间、错误原因全部封装进一个只读 ctx.Done() channel，并由 runtime 统一调度。所有监听者看到的是同一信号源，且触发时机严格可控。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 启动 worker 时必须把
ctx作为第一个参数传入，不能内部重新context.Background() - 每个 goroutine 的核心循环里，
select必须同时包含case 和业务 channel，不能拆开 - 阻塞操作必须用 context-aware 版本：比如
http.NewRequestWithContext、time.Sleep要包在select里监听ctx.Done()，不能直接调用 - 调用
cancel()后，要立刻检查ctx.Err()是context.Canceled还是context.DeadlineExceeded，决定是否记录日志或回滚事务
什么时候可以勉强用 close(done chan struct{})
只适用于：单次通知、无状态、无资源依赖、且所有接收方都处于纯 channel 监听态（不卡在 I/O 或计算中）的场景，例如服务启动完成广播、配置热重载触发点。
- done 必须是
chan struct{}，别用chan bool或chan int—— 语义不清且浪费内存 - 只能由单一协程 close，绝不能多个 goroutine 都尝试关同一个 channel
- 接收方必须用
select { case ，否则在未关闭前会永久阻塞 - 关闭后不要试图再发值，也不要对已关 channel 调
close()，否则 panic
真正难的不是发信号，而是让所有 goroutine 在任意执行点（包括 sleep、I/O、for 循环中间）都能原子响应并干净退出。这层保障，close(ch) 给不了，只有 context 的集成机制能做到——而且它要求你从函数签名、HTTP 调用、数据库查询到定时器，全都对齐同一套生命周期管理。漏掉任何一个点，就可能留下僵尸 goroutine。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
