这是Go开发里挺常见的问题，背后主要和编译器的优化逻辑、调试信息的保留情况有关，咱们一步步拆解原因：

1. 编译器内联优化的影响 #

调试模式下（不管是go run直接运行，还是VSCode调试），Go默认会禁用大部分内联优化——相当于给编译器加了-gcflags="-l"参数。这时候每个函数调用都会在栈上留下独立的栈帧，栈追踪自然能精准对应到原始的函数名和文件。

但用go build默认构建生产版本时，编译器会自动对短函数、简单函数做内联优化：把被调用函数的代码直接嵌入调用者的函数体内。这时候栈帧会被合并，原本属于customerrors.go里的函数栈帧，就会被标注成调用它的errorTest04a函数，栈帧顺序也会因为内联被打乱，看起来像是错乱了。

2. 调试信息与符号表的差异 #

调试模式下，Go会保留完整的DWARF调试符号和符号表，里面包含文件名、函数名、行号这些关键信息，栈追踪工具能精准映射到你的原始代码位置。

而生产构建的默认行为会剥离部分调试信息：比如常用的-ldflags="-w -s"优化参数，其中-w会去掉DWARF调试信息，-s会去掉符号表。缺少这些信息的话，栈追踪解析时就没办法准确对应函数和文件，自然会出现名称不匹配的错误。

3. 栈帧遍历的实现限制 #

你参考的go-errors/errors库，是通过遍历Go runtime提供的栈帧数据来生成追踪信息的。在有内联或者调试信息不全的情况下，runtime返回的栈帧数据会合并内联函数的帧，或者因为缺少符号映射，无法正确解析出原始的函数名和文件路径。而调试模式下，runtime能拿到更清晰、完整的栈帧元数据，所以输出结果符合预期。

解决办法 #

如果需要生产构建也能输出准确的栈追踪，可以调整构建参数：

# 禁用内联+保留符号表和调试信息
go build -gcflags="-l" -ldflags="-s=false"

• -l：禁用内联优化（要彻底禁用所有内联可以用-l=4）
• -s=false：保留符号表（默认-s会去除符号表，若需要行号信息，不要加-w参数）

另外也可以检查go-errors/errors的版本，新版本通常会优化内联场景下的栈帧解析逻辑，能更准确还原内联函数的信息。

内容的提问来源于stack exchange，提问作者Dave Pile