go错误堆栈需用pkg/errors.withstack或go1.13+“%w”首次封装捕获，存库应结构化拆解为func/file/line数组，过滤框架帧后截取20帧以内业务调用链，并在应用层拼接可读格式。
Go 错误堆栈怎么保留完整调用链
默认 errors.New 或 fmt.Errorf 生成的错误不带堆栈，panic 打印的堆栈又没法被捕获存库。真要存可解析堆栈，得用支持运行时捕获的错误包。
推荐直接上 github.com/pkg/errors（或 Go 1.13+ 原生 errors.Join/fmt.Errorf("%w") 配合 runtime 手动抓），但注意：只有首次封装错误时调用 errors.WithStack（或 errors.Wrap）才记录堆栈；后续只用 %w 不会更新位置。
-
errors.WithStack(err)必须在错误刚产生/刚被拦截时调用，比如 HTTP handler 里if err != nil { return errors.WithStack(err) } - 不要在每层都
Wrap，否则堆栈里全是重复的中间函数，反而难定位原始出错点 - Go 1.17+ 可用
errors.Unwrap+runtime.CallersFrames自行提取帧，但比pkg/errors多写 10 行且易漏frames.Next()循环
怎么把堆栈转成数据库能存、能查的结构
堆栈本质是一组 runtime.Frame，含 Func.Name、File、Line。直接 JSON 序列化会丢信息（比如未导出字段），也难按文件名或函数名查。
建议拆成扁平字段存进数据库表，例如：
立即学习“go语言免费学习笔记（深入）”；
CREATE TABLE error_records ( id BIGSERIAL PRIMARY KEY, message TEXT, stack_func TEXT[], -- string array, e.g. ['main.handleRequest', 'db.QueryRow'] stack_file TEXT[], -- e.g. ['/app/handler.go', '/app/db.go'] stack_line INT[] );
- 用
[]string和[]int而不是 JSON 字段，方便 PostgreSQL 的@>操作符查“是否包含某文件” - 别存完整
Frame.String()（如"main.go:42"），它不规范，解析困难；坚持用结构化字段 - 如果用 MySQL，改用 JSON 列也行，但必须预定义 schema，且查询性能弱于 PG 数组
存之前要不要过滤 / 截断堆栈
全量存太占空间，而且前几帧常是 errors.(*fundamental).Error 这类框架内部调用，对排查没用。
建议从第一个非错误包装函数开始截取——也就是跳过所有 pkg/errors 或 fmt 相关帧，找到你自己的业务代码第一帧。
- 遍历
frames时用frame.Function匹配正则^github\.com/yourorg/.*或排除^github\.com/pkg/errors/|^fmt\.|^(runtime|reflect)\. - 最多存 20 帧，再深基本是标准库循环或测试框架，无业务价值
- 别省略最后一帧（即真正 panic 或
return err的那行），那是关键现场
从数据库还原可读堆栈格式
存进去是数组，查出来不能直接扔给运维看。得拼成类似 goroutine 1 [running]:\nmain.handleRequest(0xc000124000)\n\t/app/handler.go:42 +0x1a5 的格式。
核心是补上 +0x1a5 偏移量——但它不在 runtime.Frame 里，pkg/errors 也不存。所以要么放弃偏移，要么在采集时用 frame.PC 算（需加载符号表，生产环境通常没 .go 文件）。
- 日常排查够用的格式：每行
frame.Func.Name + "\n\t" + frame.File + ":" + strconv.Itoa(frame.Line) - 如果用了
pkg/errors，它的.StackTrace()方法返回[]errors.Frame，可直接遍历，比原生runtime少处理CallersFrames状态机 - 别试图在 SQL 里拼接堆栈字符串——排序、换行、转义全乱，交给应用层做
真正麻烦的是跨服务场景：HTTP 调用链里错误经过多次序列化，堆栈容易被 toString 一遍就丢帧。这时候得靠 traceID 关联日志，而不是依赖单个错误对象里的堆栈。
