cancel() 必须显式调用才能触发父子上下文联动析构，因其本质是树形引用管理而非 gc 自动回收：不调用则子 context 持有父引用、done 通道不关闭、timer 和 goroutine 泄漏。
必须显式调用 cancel()，否则父子上下文不会联动析构 —— 这不是自动行为，而是需手动触发的资源清理动作。
为什么 cancel() 不是“自动析构”，而是关键开关
Go 的 context 取消机制本质是树形引用管理，不是 GC 自动回收。父 context（如 timerCtx）内部用 children map[canceler]struct{} 强持有子 context；子 context 也持父指针。若不调用 cancel()，这两层引用都持续存在：
-
Done()通道保持打开，监听它的 goroutine 会永久阻塞或等到超时才退出 - 父 context 的
childrenmap 不会清空，子 context 对象无法被 GC - 子 context 关联的
*time.Timer和唤醒 goroutine 也会滞留（尤其在旧版 Go 中曾引发 timer 泄漏）
defer cancel() 是最简但易错的写法
常见误用是把 defer cancel() 放在函数开头，或在错误路径中遗漏：
- 正确位置：应在
ctx, cancel := context.WithTimeout(...)后立即defer cancel()，且不能被条件分支跳过 - 错误示例：
if err != nil { return err }; defer cancel()→ 错误时cancel()永不执行 - 更安全写法：用命名返回值 +
defer闭包，或确保所有出口路径都覆盖
父子取消信号只单向传播，子 cancel 不影响父
这是常被误解的设计点：cancel() 只触发当前节点及其子孙的 Done() 关闭，父 context 完全无感：
- 调用子
cancel()→ 子和所有后代Done()关闭，子从父的childrenmap 中移除 - 父
cancel()→ 所有直接子的Done()关闭，但子 cancel 后再调父 cancel 不会 panic，只是对已移除节点无操作 - 不存在“反向析构”或“级联回滚”，父子生命周期完全解耦
真正联动析构的唯一时机：父 cancel 被调用
只有父 context 的 cancel() 执行时，才会遍历自身 children 并递归调用每个子的 cancel()：
- 这个过程发生在父
cancel()内部，不是靠 goroutine 或定时器异步触发 - 因此，若你只创建子 context 却从未调用其
cancel()，它也不会被父“顺手清理”——除非父自己也被 cancel - 典型场景如 HTTP handler：request context 是父，你在 handler 里
WithTimeout创建子 context，必须自己cancel()，不能指望 request 结束时自动帮你收尾
真正容易被忽略的是：cancel() 的调用时机决定整个链的存活时长，而它本身不消耗 CPU、不阻塞，唯一成本是 map 删除和 channel 关闭 —— 没理由省略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
