Go gosym.LineToPC 为什么在文件存在时仍返回 UnknownLineError

源码文件在磁盘上存在，并不保证其中每一行都有机器指令地址。gosym.Table.LineToPC 查询目标 Go 二进制的文件和行号记录，返回 UnknownLineError 时，应核对这一行在该构建产物中是否存在代码映射。重新检查文件读取权限通常无法解决这个问题。

官方文档：https://pkg.go.dev/debug/gosym

文件存在与行号映射有什么区别

我会先把“文件存在”拆成两件事：本地文件系统可以打开源码，以及目标产物记录了这个文件。前者无法证明后者，更无法证明源码的每一行都有对应地址。即使文件名相同，编辑器里的源码也可能已经和编译时不同。

行号表不是按源码每一行各保存一个地址的目录。空白和注释通常没有独立指令；超出文件范围的行号也可能没有映射。遇到错误时应保留“没有可用地址”的事实，不应随便取相邻行地址冒充精确结果。

怎样区分两种查询错误

官方实现先用传入的文件字符串查找 Table.Files。因此本机绝对路径未必就是表内文件键；不要只取 basename 后猜同名文件。优先展示实际键，再由调用方管理构建目录到本地目录的映射。

UnknownLineError 本身不会证明失败一定由优化造成。它也可能来自没有代码的行，或与构建产物不配套的源码行号。错误分类可以缩小问题范围，却不能代替版本核对。

如何保留错误类型和诊断信息

下面的辅助代码可放入项目包中。调用方负责先从目标二进制加载配套的 *gosym.Table，再调用 Resolve；这不是直接解析任意源码文件的独立命令，也不包含 ELF、Mach-O 或 PE 的容器读取器。

package diagnosis

import (
    "debug/gosym"
    "errors"
    "fmt"
    "sort"
)

// Resolve 使用调用方从目标产物加载的表，不检查磁盘源码。
func Resolve(t *gosym.Table, file string, line int) (uint64, string, error) {
    if t == nil || file == "" || line 

UnknownFileError 是值类型，UnknownLineError 使用指针类型，所以 errors.As 的目标变量声明不同。包装错误使用 %w，上层仍能识别原来的类型。失败时不使用返回值中的零地址，成功时也不会为了显示名称而无条件解引用 fn。

修复时要核对什么

文件键不匹配时，修正路径映射；文件键已命中时，确认行号来自编译时同一份源码。不要为了消除错误就固定加一或减一。对于没有地址的注释行，可提示用户选择可执行语句所在行。

如果工具提供“附近可用位置”，应明确标注这是近似查询，并显示实际命中的文件与行号；精确查询不能悄悄更换输入。建议诊断记录包含产物标识、文件键、请求行号、错误类型和可选函数名。公开报告时避免暴露内部构建目录。

更换产物要同步更换符号表与源码版本，不能沿用另一份产物的查询缓存。加载阶段的读取错误和符号表解码错误也应单独呈现，本例假设表已正常创建，不把空表或读取失败解释成“这一行没有代码”。

若输入来自运行中的进程地址，装载偏移属于另一层换算，不能把它直接当成文件内的静态地址。先固定产物身份，再讨论映射，通常比反复尝试邻近行号更容易解释问题。

相关问题

只有源码就能补出全部地址吗？不能。源码文本无法补造构建产物中缺失的指令映射。

下一行一定能查到吗？不能保证。如果提供邻近搜索，应限制范围并清楚显示实际命中行，不把近似结果称为原行的地址。

应该使用哪个 LineToPC？本文讨论带文件名参数的 Table.LineToPC，不要混用已弃用的旧 LineTable 同名方法，二者参数与使用背景不同。

实现阅读入口：https://go.dev/src/debug/gosym/symtab.go。