@Ayanokouji 懂你意思了 > 如果遇到 error 就打印 多数情况下是这样的，我自己是倾向于把所有 error 都打印出来，除非某个地方什么都不做，只是把 error 向上传递，也就是说 1. 产生 error 的地方记录日志 2. 处理 error 的地方记录日志 你遇到的这个问题，看起来更像是需要一个链路追踪 https://opentelemetry.io/docs/languages/go/instrumentation/ 至于直接在 error 里记录完整的调用栈也是可以的 https://pkg.go.dev/github.com/cockroachdb/errors

@Ayanokouji 那就是在最底层的那个 err 打印吧

@dylanqqt 嗯，就是最底层其实不是那么好界定，写法也比较啰嗦。不过这样的日志确实能当调用栈串联起来

@Ayanokouji github.com/pkg/errors 这个库还能再战。其实自己定义也可以，实现 error 的 struct ，增加一个 Wrap 函数，参数接受一个 error ，函数体，runtime 拿调用栈，将结果保存在 struct 的成员变量，这样就可以用了

```go err := doJob() if err != nil { return fmt.Errorf("do job failed, %w", err) } ```

@qW7bo2FbzbC0 我目前就是这种做法，这种做法的缺陷是，前缀的 message 需要足够清晰和唯一，清晰是为了可读，唯一是为了代码搜索定位当调用栈来用。 还有如果项目做国际化，这种需要定义错误吗，维护比较费精力。

这个和语言无关 错误的地方记录日志，包括当前行，当前文件 上级代码只需要知道有错误就行

和 java 的异常处理类似，底层库/函数用 errors 包装携带堆栈，上层统一捕获 error 打印即可。github.com/pkg/errors 虽然不更新了，但是够用了

两种，一种是 wrap 一下信息，我博客很多文章搜报错能直接搜到开源项目源码里去，另一种是 zap 这种 logger 能打印带文件 go:行数的

你在 error 里带上调用栈也不是不行（例如 https://github.com/go-errors/errors ），然后在顶层处理，打印或者发到 sentry 。