直接结论：仅用go build -ldflags="-s -w"无法移除panic堆栈中的绝对路径，必须配合-trimpath参数（Go 1.13+）才能将/home/user/project/main.go:12简化为main.go:12；-s -w仅移除调试符号和DWARF信息，不影响运行时通过PC地址与内置符号映射表还原的函数名和行号。
直接结论：用 go build -ldflags="-s -w" 就能移除调试符号和 DWARF 信息，让 panic 堆栈保持可读但不暴露源码路径、变量名等敏感细节。
为什么 panic 堆栈还能显示函数名和行号？
Go 运行时在 panic 时靠 PC（程序计数器）地址 + 内置的符号映射表还原函数名与行号，不依赖 ELF 文件里的 .symtab 或 .debug_* 段。所以即使你加了 -s -w，panic: runtime error 的输出仍是：
panic: invalid operation
goroutine 1 [running]:
main.main()
/home/user/project/main.go:12 +0x25
但注意：/home/user/project/ 这种绝对路径会暴露开发机结构——这是真正该警惕的“堆栈冗余”。
怎么去掉 panic 堆栈里的绝对路径？
仅靠 -s -w 不够。必须配合 -trimpath（Go 1.13+）：
立即学习“go语言免费学习笔记（深入）”；
go build -trimpath -ldflags="-s -w" -o myapp ./main.go
-
-trimpath会把所有源文件路径替换成相对路径或空字符串，让堆栈变成main.go:12而非/home/user/project/main.go:12 - 它不影响编译逻辑，只清理构建时嵌入的路径字符串
- CI/CD 中务必启用，否则每次构建都可能泄露不同开发者的本地路径
误用 -gcflags="-N -l" 会让堆栈更“臃肿”
有人想“精简堆栈”就加 -N -l（禁用优化+内联），结果反而导致：
- 函数不内联 → 调用层级变深 → panic 堆栈多出十几层无意义的中间帧
- 逃逸分析失真 → 更多变量被误判为逃逸 → 堆分配增多 → GC 频繁 → 堆栈采样开销上升
- 二进制变大、执行变慢，且
runtime.Stack()输出更长更难读
这完全背离“精简”目标。调试才用 -N -l，生产发布必须关掉。
真正影响堆栈可读性的是运行时行为，不是编译参数
编译期能控制的只是符号和路径；而实际 panic 堆栈长度、是否包含 goroutine 状态、是否截断，取决于：
- 是否调用
runtime/debug.PrintStack()（它默认只打当前 goroutine，且不带完整上下文） - 是否用
runtime.Stack(buf, all)的all参数（true会 dump 所有 goroutine，极易撑爆日志） - 是否在 defer 中反复调用
recover()导致堆栈被多次捕获叠加
这些才是线上服务里堆栈“不必要膨胀”的真实源头，比编译参数更值得盯住。
