map并发读写必然panic，因哈希表扩容时内存重排导致确定性崩溃；需用sync.rwmutex或sync.map保护，且channel必须由唯一发送方关闭。
map 并发读写 panic 是必然，不是偶发
只要多个 goroutine 同时对同一个 map 执行写操作（哪怕只有一个是写，其余是读），运行时就一定会触发 fatal error: concurrent map writes。这不是概率问题，而是底层哈希表扩容时的内存重排导致的确定性崩溃。
- 常见场景：HTTP handler 中直接往全局
map插入用户 session；中间件里缓存请求参数到共享map；配置热更新时未加锁修改映射表 - 别信“我测了 100 次都没崩”——低并发下可能侥幸绕过扩容临界点，但线上压测或流量高峰必现
- 修复不是加个
sync.Mutex就完事：读多写少时优先用sync.RWMutex；更推荐用sync.Map（注意它不支持遍历，且零值不能直接声明为字段） - 示例错写：
m["key"] = "val"在 goroutine 里裸调；正确写法：mu.Lock(); m["key"] = "val"; mu.Unlock()或sm.LoadOrStore("key", "val")
context.WithCancel 被忽略，goroutine 泄漏成常态
框架中启动的后台 goroutine（如日志 flush、指标上报、连接保活）若没监听 ctx.Done()，服务重启或超时关闭时它们会继续运行，持续占用内存和文件描述符。
- 典型错误：HTTP handler 里起 goroutine 处理异步任务，但没传入 request context；中间件注册 cleanup 函数却没绑定到 server shutdown 流程
-
runtime.NumGoroutine()持续上涨只是表象，真正难查的是那些阻塞在chan receive或semacquire的 goroutine - 必须用
select显式等待ctx.Done()，不能只靠 defer 或 global var；errgroup.Group是更安全的替代方案 - 示例隐患：
go func() { time.Sleep(5 * time.Second); doCleanup() }()—— 完全脱离生命周期控制
channel 关闭混乱引发 panic 或逻辑错位
向已关闭的 channel 发送数据会 panic：send on closed channel；而接收方用 for range 时，若发送方未关闭 channel，就会永久阻塞。
- 高频雷区：多个 goroutine 竞争关闭同一 channel；HTTP handler 中关闭 request-scoped channel 却被其他中间件重复 close
- 永远由**唯一发送方**负责关闭，接收方只应做
val, ok := 判断；用 <code>sync.Once包裹close(ch)可防重复关闭 - 无缓冲 channel 在框架层串联 middleware 时极易死锁：A 等 B 发数据，B 却在等 A 先收——改用带缓冲 channel（容量 1）或
select+default解耦 - 错误示范：
close(ch); close(ch)→ panic；for v := range ch且无人 close → goroutine 永久挂起
闭包捕获循环变量导致竞态
for 循环中启动 goroutine 并直接引用循环变量 i 或 v，所有 goroutine 实际共享同一个变量地址，最终读到的几乎总是最后一次迭代的值。
- 框架常见位置：路由批量注册、中间件链初始化、数据库连接池预热
- 不是所有情况都 panic，但结果必然错乱——比如 10 个 handler 全部处理第 10 条路由规则
- 两种安全写法：
for i := range xs { i := i; go func() { use(i) }() }或go func(i int) { use(i) }(i) - 切记：
range的 value 是拷贝，但闭包捕获的是变量本身；结构体字段若被多个 goroutine 直接赋值，同样需sync.Mutex或atomic
实际项目里最麻烦的从来不是写错一行代码，而是某处 map 写竞争没被 race detector 捕获（因为测试覆盖率低），或者某个中间件悄悄启了个 goroutine 却忘了绑 context —— 这些问题在线上跑几天才暴露，堆栈里还找不到明显线索。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
