Go中重复写if err != nil并非绕不开，但可通过提前收口错误检查、封装共性逻辑（如parseID、fetchUser）、使用errors.Join和%w格式化增强上下文来大幅减少；panic仅用于不可恢复的编程错误，禁用于业务错误；pkg/errors已基本被标准库替代，推荐自定义错误类型而非引入第三方。
Go里重复写if err != nil真的绕不开吗
绕不开，但可以大幅减少。Go的错误处理设计就是显式、直白的，不靠defer或try/catch隐藏控制流。真正的问题不是语法本身繁琐，而是很多人把错误检查和业务逻辑混在一起写，导致嵌套深、重复多、可读性差。
关键思路是：把错误检查提前收口，用函数封装共性逻辑，而不是每处都手写if err != nil。比如HTTP handler里常见模式：
func handleUser(w http.ResponseWriter, r *http.Request) {
idStr := r.URL.Query().Get("id")
id, err := strconv.ParseInt(idStr, 10, 64)
if err != nil {
http.Error(w, "invalid id", http.StatusBadRequest)
return
}
user, err := db.GetUser(id)
if err != nil {
http.Error(w, "user not found", http.StatusNotFound)
return
}
json.NewEncoder(w).Encode(user)
}
这不是“必须这么写”，而是没做抽象的典型写法。实际中可封装成parseID、fetchUser等带错误返回的函数，再配合http.HandlerFunc包装器统一处理错误响应。
用errors.Join和fmt.Errorf带上下文比裸return err强在哪
裸return err会让调用方丢失调用链信息，尤其在多层函数嵌套时，很难定位问题源头。Go 1.20+ 的errors.Join和带%w动词的fmt.Errorf能保留原始错误并叠加新上下文。
-
fmt.Errorf("failed to open config: %w", err)—— 保留原始错误类型和堆栈（如果底层支持），且可用errors.Is/errors.As判断 -
errors.Join(err1, err2, err3)—— 适合并发多个操作后汇总错误，比如批量写入文件时部分失败 - 避免
fmt.Errorf("failed: " + err.Error())—— 这会丢失原始错误类型，无法用errors.Is匹配
注意：%w只能出现在格式字符串末尾，且只接受一个error值；多个要包装请用errors.Join。
什么时候该用panic，什么时候坚决不能用
panic不是错误处理机制，是程序遇到不可恢复状态时的紧急终止手段。它不该用于业务错误（如参数非法、记录不存在），而仅限于开发阶段可捕获的编程错误或初始化失败。
- ✅ 可用：
flag.Parse()后检查必要flag是否为空；http.ListenAndServe启动失败且无法降级；全局配置解析失败导致后续必然崩溃 - ❌ 禁用：数据库查询返回
sql.ErrNoRows；用户提交了错误邮箱格式；API请求缺少必填字段 - ⚠️ 风险点：在HTTP handler里
panic会导致整个goroutine崩溃，若没配recover中间件，会返回500且无日志；生产环境应禁用未捕获的panic
第三方包如pkg/errors还值得引入吗
不推荐。Go标准库在1.13之后已通过fmt.Errorf的%w和errors包的Is/As/Unwrap覆盖了pkg/errors核心能力。继续用它只会增加依赖，且可能和标准库行为不一致（比如Wrapf vs fmt.Errorf）。
唯一例外是需要errors.WithStack类的完整堆栈追踪（标准库目前不提供运行时堆栈捕获）。但更推荐用runtime/debug.PrintStack()按需打印，或用github.com/go-stack/stack这类轻量包替代全量pkg/errors。
真正值得投入的是定义自己的错误类型（如ValidationError实现error接口），并在关键路径上用errors.As做类型断言，比依赖第三方包装更可控、更轻量。
