panic仅用于致命错误（如空指针、非法状态），常规业务失败应返回error；os.Open、json.Unmarshal等均遵循此原则；需用errors.Is/As进行错误分类，避免字符串匹配。
在 Go 中，panic 不该是常规错误处理手段，它适合程序无法继续运行的致命场景（如空指针解引用、非法状态），而非业务逻辑失败。滥用 panic 会导致调用栈中断、资源泄漏、难以测试和不可预测的恢复行为。
什么时候该用 error 而不是 panic
绝大多数函数失败都应返回 error：I/O 失败、参数校验不通过、网络超时、数据库查不到记录等。这些是预期中的“可恢复失败”，调用方需要决策——重试、降级、记录日志或向用户反馈。
-
os.Open返回error而非 panic：文件不存在是常见情况，不是 bug -
json.Unmarshal返回error：输入格式错误应由上层处理，而非崩溃 - 自定义函数如
ParseUserID(string) (int, error)遇到非法字符串应返回fmt.Errorf("invalid user id: %s", s)
哪些 panic 确实该保留
真正该 panic 的，是那些表明代码逻辑已严重错乱、继续执行无意义的点：
- 断言失败且本不该发生：
if v, ok := x.(MyInterface); !ok { panic("x must implement MyInterface") } - 并发中向已关闭 channel 发送数据（仅在开发阶段用
recover捕获调试，生产环境应避免） - 初始化阶段发现配置不可修复（如必须的环境变量缺失）：
if os.Getenv("DB_URL") == "" { panic("DB_URL required") }—— 这类可接受，因程序根本无法启动
注意：recover 不是 error 替代品，它只应在顶层 goroutine 或中间件中做兜底日志+退出，绝不用于“吞掉 panic 当正常错误”。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
如何设计可组合的 error 处理流程
Go 1.13+ 的 errors.Is 和 errors.As 让错误分类变得可靠；结合自定义错误类型和包装，能支撑清晰的控制流：
type ValidationError struct {
Field string
Msg string
}
func (e *ValidationError) Error() string { return fmt.Sprintf("validation failed on %s: %s", e.Field, e.Msg) }
func ProcessForm(data map[string]string) error {
if data["email"] == "" {
return &ValidationError{Field: "email", Msg: "required"}
}
if !strings.Contains(data["email"], "@") {
return &ValidationError{Field: "email", Msg: "invalid format"}
}
return nil
}
// 调用方可精确判断并响应
if err := ProcessForm(req); err != nil {
var ve *ValidationError
if errors.As(err, &ve) {
http.Error(w, ve.Msg, http.StatusBadRequest)
return
}
log.Printf("unexpected error: %+v", err)
http.Error(w, "server error", http.StatusInternalServerError)
}
避免用字符串匹配判断错误类型（如 strings.Contains(err.Error(), "timeout")），脆弱且无法跨包复用。
第三方库 panic 的应对策略
有些库（如旧版 database/sql 的某些方法、部分解析库）内部 panic，这时需主动封装隔离：
- 用
defer/recover在最外层包裹不可信调用（仅限该库文档明确说明“可能 panic”） - 优先升级到维护良好、明确返回
error的替代库（如用pgx替代原生sql驱动处理 PostgreSQL） - 对必须使用的 panic 型 API，写薄封装层并统一转为
error：func SafeUnmarshal(data []byte) error { defer func() { ... }(); json.Unmarshal(data, &v) }
真正的难点不在语法，而在于团队是否对“什么算致命错误”达成一致——比如空指针解引用是 panic，但空字符串作为用户名是 valid error。这类边界必须在设计接口时就写进函数注释和单元测试里。
