goroutine泄漏比数量更危险，指协程启动后因无退出路径而永久阻塞，导致runtime.numgoroutine()持续上涨、内存缓慢爬升、gc压力飙升，最终oom；典型场景包括channel发送端未关闭致接收端阻塞、select漏写default或case、协程丢弃引用后无法回收。
goroutine 泄漏比数量更危险
很多人一上来就调大 GOMAXPROCS 或狂开 go 语句，却忽略一个致命问题：协程没结束就丢了引用。泄漏的 goroutine 不会自动回收，堆栈持续占用内存，GC 压力飙升，最终 OOM。
典型泄漏场景包括：
— channel 发送端未关闭，接收端阻塞等待
— select 中漏写 default 或 case 超时兜底<br>— HTTP handler 启动协程但没绑定 <code>context.Context 的取消信号
— 循环中启动协程但没控制生命周期，比如日志异步刷盘没做限流或缓冲区满丢弃
排查手段：
— 运行时访问 /debug/pprof/goroutine?debug=2 查看存活协程栈
— 用 pprof 抓取堆栈后过滤 runtime.gopark 状态
— 在关键路径加 runtime.NumGoroutine() 打点监控趋势
sync.Pool 不是万能缓存，用错反而拖慢
sync.Pool 的价值在于复用高频分配的小对象（如 []byte、http.Header），但它本身有开销：每个 P 维护独立本地池，跨 P 获取需原子操作；且 GC 会清空所有池，导致复用率波动。
容易踩的坑：
— 把大对象（>1KB）丢进池里，拷贝成本高过新建
— 池中对象带未清理的字段（比如切片底层数组残留旧数据），引发脏读
— 在短生命周期函数里反复 Get/Put，不如直接栈分配
— 忘记在 Put 前重置字段，比如 buf = buf[:0]
建议做法：
— 只对明确高频、固定结构、大小可控的对象建池
— Put 前强制归零关键字段，或封装成 Reset() 方法
— 用 benchstat 对比启用前后的 BenchmarkAllocsPerOp
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
channel 缓冲大小不是越大越好
设缓冲区是为了缓解生产者/消费者速度差，但盲目设大（比如 make(chan int, 10000)）会带来隐性成本：内存占用翻倍、GC 扫描压力增大、甚至掩盖背压缺失问题。
真实权衡点：
— 无缓冲 channel：适合同步通知、必须配对通信的场景（如信号量）
— 小缓冲（1–64）：适配瞬时突发，比如日志采集批量投递
— 中等缓冲（128–1024）：IO 边界明确、速率相对稳定（如 DB 查询结果管道）
— 大缓冲（>1024）：只在确认下游绝对不卡顿、且内存充足时才用，否则应改用限流 + 丢弃策略
关键判断依据：
— 观察 len(ch) 长期是否趋近 cap
— 用 runtime.ReadMemStats 看 Mallocs 和 HeapObjects 是否异常增长
— 如果 channel 频繁阻塞，优先查下游处理瓶颈，而非加 buffer
数据库连接池要和 goroutine 并发数匹配
database/sql 的连接池默认最大连接数是 0（不限），但实际受限于底层驱动和数据库配置。若并发请求远超可用连接，请求会在池里排队，表现为延迟陡增、超时集中爆发。
配置要点：
— db.SetMaxOpenConns(n)：设为数据库允许的最大连接数 × 0.8，留余量给后台任务
— db.SetMaxIdleConns(m)：一般设为 MaxOpenConns 的 1/3～1/2，避免空闲连接被 DB 主动断开
— db.SetConnMaxLifetime 和 SetConnMaxIdleTime 必须设，尤其在云数据库下防连接僵死
— 用 sql.DB.Stats() 监控 WaitCount 和 MaxOpenConnections
注意：连接池不是并发控制器。如果业务层并发量失控（比如每请求启 10 个 goroutine 查 DB），再大的池也救不了——得先用 semaphore 或 worker pool 控制并发度。
context.WithTimeout 在整个调用链里的穿透深度。上游超时了，下游还在跑，资源持续占用。这比单个参数调优影响更大。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
