Go中需谨慎使用panic，仅当错误不可恢复或属逻辑崩溃点时才主动panic；自动panic包括索引越界、nil指针解引用、类型断言失败、向关闭channel发送数据。
Go 中是否需要使用 panic，核心看两点：错误是否不可恢复、是否属于程序逻辑崩溃点。不是所有错误都该 panic，绝大多数业务错误应通过 error 返回；只有当程序已无法维持基本运行状态时，才考虑主动 panic。
哪些情况适合主动 panic
主动 panic 是开发者对“不该发生却发生了”的明确表态，用于快速终止失控流程：
- 启动阶段致命缺失：如配置文件路径为空、必需环境变量未设置、数据库连接串非法且无法 fallback
- 内部逻辑断言失败：比如某个函数文档明确要求输入非 nil，但实际传入了 nil，且该 nil 不可能来自外部调用（说明代码有严重 bug）
- 违反不变量（invariant）：例如一个全局状态机本应始终处于 A/B/C 之一，结果发现是 D —— 这不是业务错误，是设计或实现错误
- 调用不安全的底层操作前兜底：如 Cgo 调用前校验指针有效性，避免 segfault
哪些情况会自动 panic（无需手动写）
这些是 Go 运行时强制保护机制，一旦触发，说明代码存在硬伤，必须修复而非捕获：
-
切片/数组/字符串索引越界：如
s[10]但len(s) == 3 -
解引用 nil 指针：如
var p *int; fmt.Println(*p) -
类型断言失败：如
i.(int)但i实际是string -
向已关闭的 channel 发送数据：如
close(ch); ch - 除零：整数除法中除数为 0（浮点数除零返回 ±Inf，不 panic）
哪些情况绝对不该 panic
滥用 panic 会让错误处理变得模糊、难以测试，也违背 Go 的设计哲学：
-
用户输入校验失败：邮箱格式错、JSON 解析失败、参数缺失 —— 应返回
error并返回友好提示 - 第三方服务临时不可用：HTTP 请求超时、DB 查询慢、Redis 连接断开 —— 应重试或降级，而不是 panic
- 可预期的业务异常：如“用户不存在”、“订单已取消”、“库存不足” —— 这些是正常业务分支，不是 panic 级别
- 用 panic 代替 if 判断：例如 “如果没查到就 panic”，这会让调用方无法区分是 bug 还是业务事实
recover 的使用前提和限制
recover 不是万能兜底，它只在特定条件下有效：
-
必须在 defer 函数中调用：单独写
recover()没有意义，永远返回nil - 只能捕获同 goroutine 的 panic：子协程 panic 不会影响主线程，也无法被主线程 recover
- 不能跨函数恢复：panic 发生在函数 A，recover 写在函数 B 里（且 B 不是 A 的 defer）—— 无效
- recover 后程序继续执行，但状态可能已损坏：比如 panic 前已修改全局变量、已写入部分文件 —— recover 不等于回滚
基本上就这些。判断要不要 panic，就问自己一句：这个错误发生后，我还能相信当前函数乃至整个 goroutine 的状态吗？不能，就 panic；能，就用 error 处理。
