Go的错误处理太单薄了，pkgerrors给它加上下文

Go的错误处理太单薄了，pkg/errors给它加上下文

写 Go 的程序员每天敲得最多的代码，大概就是 if err != nil { return err }。这种处理方式本身没毛病，问题在于错误从底层一层层往回传的时候，每一层的调用信息、参数状态、当时在做什么，全丢了。

线上出了故障，日志里能看到的就只有一句 "connection refused" 或者 "permission denied"，至于这个错误是哪个函数、在处理哪条数据时触发的，一片空白。

pkg/errors 就是来解决这个问题的。这个库由 Go 社区的 Dave Cheney 开发，目前在 GitHub 有 8300 多 Star。

它的设计思路一句话就能说清：在错误传递的每一环，把"我这里在做什么"贴到原始 error 上，形成一条可追溯的上下文链路。两个函数撑起了这个思路。

Wrap：给错误加上下文

errors.Wrap 接收一个原始 error 和一段描述，返回包装后的新 error：

_, err := ioutil.ReadAll(r)
if err != nil {
    return errors.Wrap(err, "read failed")
}

被 Wrap 过的错误继续往上抛，到了最外层就能看到上下文链：哪一步读文件失败了，哪个环节网络超时了，一清二楚。

Cause：追溯错误根因

Wrap 的反向操作是 errors.Cause，递归剥掉所有包装层，拿到最底层的原始 error：

switch err := errors.Cause(err).(type) {
case *MyError:
    // 处理已知错误类型
default:
    // 未知错误兜底
}

上层靠上下文做日志记录和问题定位，底层靠类型断言做分支处理。各取所需，互不干扰。

---

怎么用

安装就一条命令：

go get github.com/pkg/errors

使用时把标准库的 errors.New 和 fmt.Errorf 替换为 pkg/errors 的对应版本即可。习惯上只有一条：每次手动向上传递 error 的地方都 Wrap 一下，不要让上下文链在某一环断掉。

---

当前状态

pkg/errors 已进入维护模式，不再接受功能新增提案，只处理 bug 修复和已有 PR 的合并。

原因是 Go 语言自身在错误处理上持续演进。从 Go 1.13 开始，fmt.Errorf 支持了 %w 动词做错误包装，标准库新增 errors.Is 和 errors.As 用于错误链的判断和类型提取。这些原生能力覆盖了 pkg/errors 的大部分使用场景。

但标准库至今仍有两个空缺：一是错误里不自动附带堆栈信息，二是不兼容 Go 1.13 之前的项目。如果你的项目还跑在较低版本上，或者需要堆栈信息辅助定位，pkg/errors 仍是一个可选项。

---

Go 的错误处理被讨论了十几年。pkg/errors 没有发明一套新范式，也没有推翻 if err != nil 的习惯。它只做了一件事：让每一个 error 不再是一句孤立的消息，而是一条带上下文和追溯能力的记录。这个价值，在凌晨四点排查生产事故时，体会最深。