深层嵌套函数中cancel()失效的根本原因是某层未检查ctx.done()或使用阻塞操作，context不会自动冒泡，必须显式传参；每层都需接收ctx、用select监听done()、避免阻塞调用、正确调用cancel()覆盖所有退出路径。
深层嵌套函数里 cancel() 没生效，不是 context 传不下去，而是某一层根本没检查 ctx.Done()，或者用了阻塞操作卡死在那儿——信号早到了，只是你没听见。
每层函数都必须显式接收并使用 ctx 参数
context 不会自动“冒泡”或“查找”，它只靠你手把手传参向下流动。漏掉一层，下游就彻底失控。
- 错误写法：
func worker() { go subWorker() }→subWorker拿到的是context.Background()，和上游取消完全无关 - 正确写法：
func worker(ctx context.Context) { go subWorker(ctx) }，且subWorker也声明ctx context.Context参数 - HTTP handler 中常见断裂点：中间件调了
log.Printf()，而日志库内部启了 goroutine 却没透传ctx - 闭包捕获外部
ctx变量（如go func() { doWork(ctx) }()）风险极大——协程启动时ctx可能已是旧值或未初始化
阻塞操作必须替换成可取消的等价形式
写 time.Sleep(2 * time.Second) 就等于关掉耳朵等两秒，期间 ctx.Done() 关了你也听不见；所有等待点都要用 select 并行监听。
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 别用：
time.Sleep(d)、chan（无超时）、<code>for range ch（无退出条件） - 改用：
select { case - 对支持 context 的标准库操作，直接传
ctx：比如http.NewRequestWithContext(ctx, ...)、db.QueryRowContext(ctx, ...) - 第三方库不支持 context？自己封装一层
select+donechannel，别硬等
WithTimeout 的超时起点容易误判
超时不是从请求开始算，而是从 context.WithTimeout 执行那一刻起——DNS 解析、锁竞争、GC STW 都算进去。真正发请求时可能只剩毫秒级时间。
- 想让“网络请求发出”才开始计时？就在
http.Client.Do()前一刻才调context.WithTimeout(ctx, ...) - 嵌套多个
WithTimeout会导致总耗时不等于各层之和，外层包含内层构造开销；建议只在外层设主超时，内层复用或用WithValue -
timerCtx必须显式cancel()：哪怕请求 200ms 就返回，不调cancel()，那个*time.Timer还会跑完剩余时间，延迟传播取消信号 - 验证泄漏：用
go tool pprof -http=:8080 http://localhost:6060/debug/pprof/goroutine?debug=2查看是否堆积大量runtime.timerproc
取消信号传播不是广播，是线性遍历
父 cancelCtx 调 cancel() 时，并非瞬间通知所有子节点，而是递归遍历 children map，逐个调子节点的 cancel()——嵌套越深，传播延迟越明显。
- 5 层嵌套下，实测取消触发后 2–3ms 才传到最深层 goroutine
-
valueCtx不参与取消，但会延长遍历路径（需跳过它才能找到下一个可取消节点） - 高频请求中
childrenmap 元素达数千个，单次cancel()耗时可从微秒升至毫秒级 - 避免无意义的多层
WithCancel：同一父ctx下多次调context.WithCancel会创建多个独立取消通道，破坏树形一致性
最常被忽略的点：cancel() 必须覆盖所有退出路径，不止 defer。函数有多个 return、panic 后 recover、或提前返回时，defer cancel() 根本不会执行——漏一次，就多一个泄漏的 timer 和 goroutine。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
