滥用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 检查，失败则返回 error，而非依赖 panic 捕获
• 类型断言失败（i.(string)）→ 用安全形式 v, ok := i.(string)，!ok 就走错误分支
• map 查不到 key 就 panic → map 访问本身不 panic，只有对 nil map 赋值才 panic；查不到 key 是正常逻辑，应默认值或返回 error

跨 goroutine 的 panic 必须拦截

子 goroutine 中的 panic 不会自动传播到主 goroutine，但若未捕获，会直接终止该 goroutine 并丢失堆栈，极难排查。

• 手动封装：每个 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 来打补丁。