Go trimpath 后怎样保留可用的错误定位

Go 使用 go build -trimpath 后，仍可依靠文件名、行号和对应的源码版本定位错误。关键是把构建机绝对路径换成可映射的逻辑路径，并随发布保留源码与构建记录；不要把去掉绝对路径理解为删除全部定位信息。

下面做一个只依赖标准库的小程序：记录一条主动产生的错误，并输出发布标识、源码文件和行号。正文中的运行观察是供读者核对的预期，不是已执行测试的记录。

官方构建说明：https://pkg.go.dev/cmd/go；Caller 文档：https://pkg.go.dev/runtime#Caller。

1. 先分清被裁掉的路径和仍需保留的定位信息

官方构建参数说明，-trimpath 用模块路径及版本或导入路径形式记录文件名，代替文件系统绝对路径。具体前缀受主模块、依赖模块、标准库及构建方式影响，不能统一猜成“模块名@版本/文件”。主模块开发构建尤其不能假定一定含有版本后缀。

这里的“文件名”是定位元数据中的名字，不一定是运行机器上能直接打开的文件。路径被改写后，日志中的 file 和 line 仍应一起保留；发布记录中的 releaseID 则用来选择源码版本。若只保留 main.go 这样的 basename，多个包里的同名文件会难以区分。

2. 准备一个独立的示例模块

在空目录里创建模块，再保存下一节的 main.go。示例地址使用 example.com 的示例命名空间，不代表需要下载外部库。后续两次构建使用同一份源码，避免把改动行号与路径变化混在一起。

# 只在新的示例目录初始化一次模块。
go mod init example.com/trimpathdemo
# 确认本机 Go 工具版本，随构建记录保存。
go version

本步骤的结果是当前目录有 go.mod 和即将创建的 main.go。本文没有让程序读取源码文件，避免把 Caller 返回的逻辑名字误当运行环境的磁盘地址。

3. 在错误记录中保留完整文件、行号和发布标识

下面的 recordError 在调用点取定位信息：runtime.Caller(1) 跳过 recordError 这一层，指向调用它的函数。这个位置是记录错误的地方，不保证就是错误最初发生的地方。包装层增加时，skip 也不能机械照抄。

package main

import (
    "fmt"
    "log"
    "os"
    "runtime"
)

// 默认标识用于本地示例，正式构建应传入可追溯标识。
var releaseID = "local-demo"

func recordError(err error) {
    if err == nil {
        return
    }
    // 跳过本函数，定位调用 recordError 的位置。
    _, file, line, ok := runtime.Caller(1)
    if !ok {
        file, line = "unknown", 0
    }
    // 保留完整逻辑路径，不只记录 basename。
    log.Printf("release=%q file=%q line=%d err=%q",
        releaseID, file, line, err.Error())
}

func main() {
    log.SetOutput(os.Stderr)
    // 示例省略时间字段，专门观察路径和定位字段。
    log.SetFlags(0)
    recordError(fmt.Errorf("订单示例：数量必须大于零"))
}

这个错误是主动构造的演示输入，不是订单系统真实事故。普通 error 值不会因为开启 trimpath 就自动带上调用栈；示例明确调用 Caller 来补充记录位置。Caller 的 ok 为 false 时保留 unknown，不能伪造一个文件位置。

4. 对比普通构建与 trimpath 构建

用下面两条构建命令产生不同文件名的可执行文件，避免相互覆盖。两者都保留常规构建配置，唯一要比较的路径参数是 -trimpath。releaseID 只是手动示例标签，不能当作自动识别的提交哈希。

# 普通构建保留原有源码路径记录方式。
go build -o locate-normal -ldflags="-X main.releaseID=demo-source-a" .
# 使用相同源码及标识，只改变路径处理参数。
go build -trimpath -o locate-trim -ldflags="-X main.releaseID=demo-source-a" .
# 在类 Unix 环境分别观察错误记录。
./locate-normal
./locate-trim

Windows 读者可在输出文件名上使用 .exe，并按其终端规则执行对应文件。比较时看三个字段：file 的构建机路径前缀是否变成逻辑前缀；line 是否仍能对应同一份 main.go 的记录调用处；release 是否仍为 demo-source-a。不应从本文复制某个固定行号作为成功标准，因为自行增删注释也会改变行号。

若日志原来由其他组件只保留短文件名，先分清那是日志格式化行为还是构建路径改变。不要为了恢复目录信息，重新在业务日志中硬编码构建机器的私人绝对路径。

5. 让发布源码能接住逻辑路径

正式接入时，把 releaseID 映射到一次明确的源码快照和构建记录，记录 Go 工具版本、构建参数、主模块及依赖版本。不能用“最新源码”替代发布源码：同一个文件名在不同提交里可能已有不同的行号含义。

逻辑文件路径 与 源码快照 共同定位 源码文件，再由 line 选择相关位置。依赖中的位置应匹配对应依赖源码；本地 replace、生成文件或未提交改动也需要在保存的构建输入中体现。本文的小程序没有外部依赖，但这项规则不能在真实部署时省略。

程序运行不需要把整个源码目录随可执行文件一起部署，排障端却应能取得对应源码。若工具仍要求运行机器上的绝对路径，需要按工具支持方式配置源码映射，而不是假定逻辑文件路径可以直接 os.Open。

6. 最后区分路径变化与其他定位失败

trimpath 能清掉所有敏感信息吗？不能把它当通用脱敏工具。程序自己写入的字符串、日志、嵌入资源和业务数据需要单独管理，模块或包名本身也可能透露项目信息。

它会把运行时文件读取路径也改掉吗？业务代码传给 os.Open 等函数的路径不是该参数所描述的源码定位字段；不能依靠 trimpath 修复或重写这些路径。

一定要关闭优化才能查错误吗？本示例不要求改变优化选项。这里讨论的是文件路径映射，不把优化、调试符号配置或调试器行为混成同一个问题，也不承诺所有调试工具零配置可用。

保留可用错误定位的最小组合是：完整逻辑文件名、行号、可追溯发布标识和对应源码。trimpath 去掉的是构建环境路径依赖，源码对应关系则需要发布流程主动保留。