panic退出码固定为2，无法修改；自定义退出码必须用os.Exit；recover仅拦截panic传播，需配合os.Exit实现带码退出。
panic 本身不控制退出码，os.Exit 才能指定
Go 的 panic 是运行时异常机制，触发后会打印堆栈并以状态码 2 退出（硬编码在 runtime 中），无法修改。真正能自定义退出码的只有 os.Exit。很多人误以为 recover 后调用 panic 就能改码，其实只是多了一次 panic，最终还是走默认路径。
-
panic的退出码固定为 2，无论 recover 是否发生、是否嵌套 - 想用非 2 的码（比如 1 表示业务错误、127 表示命令行参数错），必须显式调用
os.Exit(n) - recover 只是拦截 panic 的传播，不是“重写 panic 行为”
用 defer + recover + os.Exit 实现“带码 panic”
常见做法是在 main 函数开头 defer 一个 recover 处理器，捕获 panic 后解析错误类型或消息，再决定调用 os.Exit 的具体码。注意：recover 必须在 panic 同一 goroutine 中调用才有效。
- 不要在 goroutine 里直接 panic 后指望主 goroutine recover —— 它收不到
- recover 返回的是
interface{}，需类型断言或用fmt.Sprint转成字符串判断关键词 - 避免在 recover 里再 panic，否则又回到退出码 2
func main() {
defer func() {
if r := recover(); r != nil {
switch r := r.(type) {
case string:
if strings.Contains(r, "invalid arg") {
os.Exit(127)
}
case error:
if errors.Is(r, errInvalidConfig) {
os.Exit(1)
}
}
os.Exit(1) // 默认业务错误码
}
}()
// ... 业务逻辑，可能 panic
}
os.Exit 会跳过 defer，panic 不会
这是关键行为差异：os.Exit 立即终止进程，所有未执行的 defer 全部丢弃；而 panic 会先跑完当前 goroutine 的 defer 链，再退出。如果你有清理逻辑（如关闭文件、释放锁），放在 defer 里对 panic 有效，但对 os.Exit 无效。
- 依赖 defer 关闭资源？用 panic + recover + os.Exit 组合，别直接 os.Exit
- 想确保某段清理代码必执行，不能靠 os.Exit 前的手动调用 —— 进程可能被信号中断或死锁卡住
- log.Fatal 本质是 print + os.Exit(1)，同样跳过 defer
为什么不用 signal.Notify 拦截 SIGTERM 来统一处理？
因为 panic 和 os.Exit 都是同步流程，和系统信号无关。signal.Notify 用于响应外部 kill 命令，和程序内部崩溃无关。混用反而增加不确定性：比如 panic 正在执行 defer 时收到 SIGTERM，两个退出路径竞争。
立即学习“go语言免费学习笔记（深入）”；
- 不要试图用 signal.Notify “兜住” panic —— 它根本收不到
- 如果要支持优雅退出（如正在处理 HTTP 请求时 shutdown），那是另一个维度的问题，和 panic 退出码无关
- 真正要统一退出逻辑，应封装一个
exit(code int, msg string)函数，内部先做清理，再 os.Exit
