看到 fatal error: all goroutines are asleep - deadlock! 就该立刻停手查 channel 缓冲配置，这不是程序卡顿，而是 go 运行时确认所有协程都陷入“等不到对方就绪”的状态后主动终止；需立即分析 panic 日志中的 goroutine 堆栈，定位卡在 chan send/recv 的具体行，区分无缓冲通道的同步阻塞与带缓冲通道因满/空导致的延时死锁。
看到 fatal error: all goroutines are asleep - deadlock! 就该立刻停手查 channel 缓冲配置
这不是程序卡顿，是 Go 运行时确认所有协程都陷入“等不到对方就绪”的状态后主动终止。缓冲区配置不当（比如该用带缓冲却用了无缓冲、缓冲大小与业务节奏不匹配）是最常见的诱因之一。关键不是猜逻辑，而是看 panic 日志末尾的 goroutine 堆栈——尤其是哪一行在阻塞、哪些 goroutine 全卡在 chan send 或 chan recv。
- 无缓冲 channel（
make(chan int)）本质是同步握手：发送方必须等到接收方 ready 才能继续；漏掉任意一端，就是死锁温床 - 带缓冲 channel（
make(chan int, 10)）只是延缓死锁：当len(ch) == cap(ch)时，再 send 就阻塞；当len(ch) == 0且未关闭时，再 recv 就阻塞 - 缓冲大小 ≠ 并发数：设成 100 不代表能扛住 100 个并发写入，如果消费者处理慢、积压满，后续写入仍会挂起
select 没 default + 缓冲区满/空 = 主 goroutine 直接死锁
这是高发场景：你用 select 等待一个带缓冲 channel，但没加 default，又没配超时，一旦 channel 满（send）或空（recv），当前 goroutine 就挂起。如果这是 main goroutine，且没有其他活跃协程，立刻触发死锁。
- 错误写法：
select { case ch —— channel 满时永久阻塞 - 临时缓解：
select { case ch ，但注意 <code>default是非阻塞轮询，高频下需加runtime.Gosched()或小延时，否则吃 CPU - 真正解法：结合
time.After做超时控制，或用context.WithTimeout统一管理生命周期
用 go tool trace 定位“谁在等谁”比看日志更直接
pprof 的 goroutine profile 只能看到栈帧，而 go tool trace 能还原状态变迁时间线，一眼看出哪个 goroutine 长期处于 chan send 或 chan recv，且无对应唤醒者。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 启用方式：启动前加
import _ "net/http/pprof"和go http.ListenAndServe("localhost:6060", nil) - 采集 trace：
curl "http://localhost:6060/debug/trace?seconds=5" -o trace.out - 分析重点：打开 Web UI → “Goroutine” 标签页 → 筛选状态为
chan send→ 查看该 goroutine 是否长时间停留、有无 sender/receiver 成对出现 - 兼容提示：Go 1.20+ 对 channel 阻塞点追踪更细，旧版本建议升级
close() 时机和主体错乱会让缓冲区配置失效
即使用了带缓冲 channel，如果 close() 由错误 goroutine 执行、或执行太早/太晚，消费者仍可能永远等不到 EOF，导致 for v := range ch 卡死，最终演变为死锁。
- 常见错误：生产者 goroutine 发完数据就
close(ch)，但消费者还没启动；或多个 goroutine 争抢close()，造成panic: close of closed channel - 安全模式：只由唯一 producer goroutine
defer close(ch)，consumer 用v, ok := 或 <code>for range主动判断关闭 - 缓冲区再大也救不了：如果没人关 channel，receiver 即使读完所有缓冲数据，也会继续等待新数据，直到所有 goroutine 都阻塞
缓冲区配置不是调参游戏，它和谁发、谁收、谁关、何时退出强耦合。最容易被忽略的是：无缓冲 channel 的长度永远是 0，len(ch) 完全不能用来判断可写性；而带缓冲 channel 的满/空状态，只有在明确知道当前并发节奏和消费能力的前提下，才有意义。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
