滥用panic本质是错误处理权错配；该用error而非panic的核心判断是调用方能否/应否响应失败：能则返回error，不能且继续执行会致状态污染才考虑panic。
滥用 panic 的本质，是把本该由调用方决策的错误处理权，强行收归运行时——结果不是兜住问题，而是掩盖设计缺陷。
什么时候该用 error，而不是 panic
核心判断只有一条：调用方能否、是否应该对这个失败做出响应？能，就返回 error；不能，且继续执行会导致状态污染或数据损坏，才考虑 panic。
- 文件读取失败 →
os.ReadFile返回error，调用方可重试、降级、提示用户 - 配置项缺失导致服务根本无法启动 →
init中panic("missing required config: DB_URL")，因为没有它，后续所有逻辑都无意义 - HTTP handler 里解析 JSON 失败 → 必须返回
error（如json.Unmarshal错误），写入 400 响应，绝不panic - 库函数中遇到非法参数（如空字符串传给必须非空的 ID）→ 返回
error，而非panic；库不掌握上层上下文，无权决定程序生死
哪些 panic 场景其实该用 error
这些是高频误用点，表面看“很严重”，实则完全可恢复、也理应由业务层处理：
-
nil指针解引用前没检查 → 应提前判空并返回error，而不是等 runtime panic - 切片索引越界（如
slice[i]）→ 先用i 检查，失败则返回 <code>error，而非依赖 panic 捕获 - 类型断言失败（
i.(string)）→ 用安全形式v, ok := i.(string)，!ok就走错误分支 - map 查不到 key 就 panic → map 访问本身不 panic，只有对
nilmap 赋值才 panic；查不到 key 是正常逻辑，应默认值或返回error
跨 goroutine 的 panic 必须拦截
子 goroutine 中的 panic 不会自动传播到主 goroutine，但若未捕获，会直接终止该 goroutine 并丢失堆栈，极难排查。
立即学习“go语言免费学习笔记（深入）”；
- 手动封装：每个 goroutine 入口加
defer+recover，把 panic 转成error发到 channel - 推荐用
errgroup.Group：它内部已封装了 recover 逻辑，g.Wait()会聚合所有 panic 转换的 error - 注意：
recover只在defer函数中有效，且只能捕获**当前 goroutine** 的 panic；不要试图在别处 recover
func worker(id int) error {
defer func() {
if r := recover(); r != nil {
// 把 panic 转为 error，保持语义统一
panic(fmt.Errorf("worker %d panic: %v", id, r))
}
}()
if id == 2 {
panic("simulated panic")
}
return nil
}对外暴露的 API 绝对禁止 panic
这是 Go 生态的硬性契约。你的函数一旦 panic，调用方毫无防备——它没写 recover，程序就崩了；写了 recover，又违背了“错误应显式传递”的 Go 哲学。
- 所有导出函数（首字母大写）的签名必须包含
error返回值 - 内部工具函数若真需 panic（如断言关键不变量），应设为 unexported（小写开头），且文档注明“仅限内部使用”
- 测试中用
panic做断言（如testify/assert）没问题，但生产代码里不行
最常被忽略的一点：很多开发者以为 “recover 住了就不算 panic”，于是放心在业务逻辑里用 panic —— 但 recover 后你拿到的是一个中断的、不可预测的执行状态，不是“恢复了”，只是“没崩溃”。真正健壮的 Go 代码，95% 的错误路径都该走 error 分支，而不是靠 defer+recover 来打补丁。
