协程 panic 总找不到源头是因为其不跨 goroutine 传播，main 中的 defer/recover 对子协程无效，导致 panic 静默退出、无日志、无堆栈；必须在每个 goroutine 内部用 defer+recover 捕获，或通过 runtime/debug.settraceback("all") 和 sigquit 栈 dump 定位，goland 中需手动开启 show goroutines 并结合启动行号与变量区分。
协程 panic 为什么总找不到源头
Go 的 goroutine panic 不会跨协程传播，main 里的 defer/recover 对子协程完全无效。现象是程序偶尔卡住、日志断层、HTTP 请求无声失败——但没报错、没堆栈、没 panic 日志。这不是“没出错”，而是错误被静默吞掉了。
必须启用的全局异常钩子
靠每个 go 语句手动加 defer/recover 容易漏，尤其第三方库启动的协程。生产环境第一道防线是设置全局未捕获 panic 钩子：
runtime.SetPanicHandler（Go 1.22+）或 debug.SetPanicOnFault（仅限特定平台）都不够用；真正有效的是在 main 函数开头注册 runtime/debug.SetTraceback("all")，并配合 os/signal 捕获 SIGQUIT 触发栈 dump：
signal.Notify(sigChan, syscall.SIGQUIT); go func() {
更实用的做法是：启动时加 GODEBUG=panicstack=1 环境变量，能让所有未 recover 的 panic 至少输出基础调用栈到 stderr。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
pprof + debug=2 看“活着但已死”的协程
很多协程 panic 后没退出，只是卡在 runtime.gopark 或 runtime.chanrecv，表面看是阻塞，实际是崩溃后残留。这时 /debug/pprof/goroutine?debug=2 就很关键：
- 重点搜
created by行——它指向协程启动位置，比堆栈顶部更准 - 若看到大量协程停在
runtime.panicwrap或runtime.startpanic，说明它们刚 panic 还没被调度器清理 - 对比两次快照：
curl -s http://localhost:6060/debug/pprof/goroutine?debug=2 > a.txt，等 10 秒再抓 b.txt，用diff -u a.txt b.txt | grep '^+' | grep 'created by'找新增来源
调试器里别忽略 Goroutines 标签页
GoLand 默认不显示协程列表，不是没数据，是 UI 被折叠了。必须手动点 Debug 窗口右上角 Show Goroutines（快捷键 Ctrl+Shift+G），否则你永远只看到当前断点所在的那一个 goroutine。
开启后注意三点：
- 每个
goroutine悬停时显示启动行号（如handler.go:87），这是定位匿名协程最直接依据 - 若多个协程启动位置相同（比如 for 循环里起的），就看 Variables 面板里传入的
id或ctx值来区分 - 别信栈顶函数名——
runtime.goexit是正常终点，第二层才是你的业务函数
真正的难点不在发现 panic，而在确认它是否已被 recover；一旦协程卡在 runtime.gopark 且堆栈里没有 recover 调用痕迹，基本就是漏处理了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
