绝大多数失败场景该用 error，而非 panic；error 用于可预期、可恢复的业务错误，如文件不存在、JSON 解析失败；panic 仅用于程序无法继续运行的致命缺陷，如关键配置缺失、逻辑矛盾或不可达分支。
什么时候该用 error，而不是 panic
绝大多数你遇到的失败场景，都应该用 error —— 它是 Go 的“常规错误通道”，不是缺陷，而是设计的一部分。
常见错误现象：调用 os.ReadFile("missing.txt") 返回非空 err；json.Unmarshal 解析非法 JSON；HTTP 客户端收到 404 或超时。这些都不是程序崩了，只是“事情没办成”，调用方完全能判断、重试、降级或返回友好提示。
- 参数校验失败（如 ID 为空、邮箱格式不对）→ 返回
errors.New("invalid email") - 数据库查询无结果 → 返回
sql.ErrNoRows，而非 panic - 第三方 API 返回 503 → 包装为自定义
error，供上层决定是否退避重试 - 所有 I/O、网络、编码类操作，默认走
error路线；Go 标准库几乎全部如此
哪些情况才允许触发 panic
panic 不是“更严重的 error”，它是“程序已无法信任自身状态”的熔断信号。一旦发生，继续运行可能污染数据、掩盖真正 bug，甚至引发竞态或内存泄漏。
典型触发点：
立即学习“go语言免费学习笔记（深入）”；
- 程序启动时关键配置缺失且无默认值：
if cfg.DBURL == "" { panic("DBURL required") } - 本应存在的全局对象被意外置为
nil（比如注册的 logger 未初始化就调用） - switch 枚举穷举后漏掉
default，却走到了不可能分支：case StateDone: ... default: panic("unreachable: state=" + s.String()) - 手动检测到逻辑矛盾：
if len(data) != expectedLen { panic("inconsistent data length") }
注意：panic 不该用于处理用户输入、网络抖动、磁盘满等可恢复或可预期状况 —— 这些都属于业务流程的一部分，不是程序崩溃的理由。
别在 defer 中滥用 recover 拦截 panic
recover 只应在极少数边界场景下使用，比如 HTTP handler 顶层兜底防止整个服务因单个请求 panic 而退出；或测试中模拟崩溃行为。
常见错误现象：在每个函数里写 defer func(){ if r := recover(); r != nil { log.Printf("recovered: %v", r) } }() —— 这等于把 panic 当 error 用，掩盖了本该暴露的逻辑缺陷。
- recover 后不重新 panic 或明确返回错误，会导致函数看似成功返回，但实际状态已损坏
- goroutine 内部 panic 若未 recover，会直接终止该 goroutine，但不会影响主流程 —— 这不是 bug，是 Go 的设计
- 永远不要用 recover 来“绕过”数组越界或 nil 指针解引用：它们暴露的是代码 bug，该修代码，不该加 recover
容易被忽略的底层事实
Go 运行时自动触发的 panic（如 index out of range、nil pointer dereference）和你手动 panic 在语义上是一致的：都表示“当前 goroutine 已无法安全继续”。区别只在于谁发现的 —— 是编译器/运行时，还是你自己。
这意味着：如果你主动 panic("config missing")，和忘记判空导致 *nilPtr 崩溃，在运维视角下没有本质区别 —— 都是进程退出、日志报错、需要人工介入。所以真正的分水岭不在“谁调用 panic”，而在于“这个失败是否本可被提前检查并返回 error”。
一个简单心法：如果错误发生前，你能用 if 判断条件并选择返回 error，那就别 panic。panic 留给那些连 if 都写不出来的地方 —— 比如“这行代码理论上根本不可能被执行到”。
