defer在goroutine中无效，因其仅在函数返回时执行，而goroutine常因阻塞永不返回；正确做法是用context.context控制生命周期，所有阻塞操作需select监听ctx.done()，并由启动方负责调用显式close()或cancel()。
Go 里没有“对象销毁”概念，所谓“自定义销毁函数”，本质是靠 defer、context.Context 或显式回调，在资源持有者退出或失效时触发清理逻辑。不靠语言机制兜底，全靠你写对时机和顺序。
为什么不能依赖 defer 在 goroutine 里做清理
defer 只在**当前函数返回时**执行，而 goroutine 的生命周期和函数调用栈无关。如果 goroutine 卡在 select、ch 或 <code>time.Sleep 上，它永远不会 return，defer 就永远不会跑。
- 错误示例：
go func() { defer close(ch); for { ch —— <code>ch永远不会被关闭，因为函数没 return - 真正需要的是：让 goroutine 主动感知退出信号，然后自己调用清理逻辑（比如
close(ch)、conn.Close()、ticker.Stop()） - 所有阻塞操作必须包裹在
select中，并包含分支
如何设计可销毁的资源封装类型
把资源 + 清理逻辑打包成结构体，提供明确的 Close() 方法，而不是散落在各处的 defer。
- 结构体字段应包含所有需释放的资源：如
*sql.DB、net.Conn、*time.Ticker、sync.Mutex等 -
Close()方法要幂等：多次调用不应 panic，可用sync.Once控制执行一次 - 避免在
Close()里调用阻塞操作（如等待 channel 关闭），除非你确定接收方已就绪 - 示例：
type Client struct { conn net.Conn; mu sync.RWMutex; once sync.Once }; func (c *Client) Close() { c.once.Do(func() { c.conn.Close() }) }
谁该调用销毁函数？关键在责任归属
销毁责任必须清晰，不能靠“有人会关”。常见错误是把 cancel() 或 Close() 传进 goroutine 内部，结果调用方忘了调，或者调了但 goroutine 已卡死无法响应。
- 启动 goroutine 的代码，必须同时负责它的生命周期终结 —— 这意味着你要保存
cancel函数或Close方法引用 - HTTP handler 中启 goroutine 处理异步任务？用
req.Context()，并在 handler 返回前确保cancel()被调用（通常用defer cancel()） - 工作池模式下，worker goroutine 的退出由 channel 关闭驱动，主逻辑负责
close(taskCh)，worker 自己检测并退出 - 切忌：在
defer里再起 goroutine 做清理（如日志上报），若没传ctx或没设超时，它可能永远卡住
最易被忽略的一点：销毁函数本身可能依赖其他资源（比如关闭连接前要发 goodbye 包），这些依赖也得有超时或取消机制，否则 Close() 会成为新的阻塞点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
