Go 自建类型检查器怎样复用解析阶段的 FileSet

自建 Go 类型检查器时，应把解析阶段的 *token.FileSet 原样传给 types.NewChecker，并在解释声明位置时继续使用它。同一个包的多个源码文件可以共用这份表。不要在解析完 AST 后，另外创建空 FileSet 交给检查器。

官方文档：https://pkg.go.dev/go/types#NewChecker；位置表说明：https://pkg.go.dev/go/token#FileSet。

把 FileSet 当作整轮分析的上下文

AST 中的 token.Pos 是一个位置值，不独立携带文件名、行号和列号。解析器将文件登记到 FileSet，再把相应位置写进 AST。检查器接收这些 AST 时，需要知道它们所属的位置上下文。

可以将 FileSet、AST 列表、Package 和 Info 放入一个分析任务对象，在调用链上整体传递。这样业务层拿到 AST 时，也能拿到解释它所需的位置表。这里复用的首要目的，是保证位置对应关系一致；本文没有测量速度或内存收益。

同一位置表完成解析和类型检查

下面的完整示例把两个字符串作为同一个包的两个文件，解析和检查均使用同一 FileSet。源码没有 import，因此无需配置 Importer；真实项目包含依赖时，需要另行选择导入器或项目包加载方案。示例为原创说明代码，本文没有执行。

package main

import (
 "fmt"
 "go/ast"
 "go/parser"
 "go/token"
 "go/types"
)

func main() {
 // 同轮解析和检查始终使用这份位置表。
 fset := token.NewFileSet()
 sources := []struct{name, text string}{
  {"model.go", "package demo\ntype Item struct { Count int }\n"},
  {"use.go", "package demo\nfunc Total(v Item) int { return v.Count }\n"},
 }
 var files []*ast.File
 for _, src := range sources {
  file, err := parser.ParseFile(fset, src.name, src.text, 0)
  if err != nil {
   fmt.Println("解析失败：", err)
   return
  }
  files = append(files, file)
 }
 // 按需收集声明对象，避免申请无关的语义信息。
 info := &types.Info{Defs: make(map[*ast.Ident]types.Object)}
 pkg := types.NewPackage("example.com/demo", "demo")
 conf := &types.Config{Error: func(err error) {
  // 诊断中的位置与其自带的 FileSet 配对使用。
  if e, ok := err.(types.Error); ok {
   fmt.Printf("%s: %s\n", e.Fset.Position(e.Pos), e.Msg)
   return
  }
  fmt.Println(err)
 }}
 checker := types.NewChecker(conf, fset, pkg, info)
 if err := checker.Files(files); err != nil {
  // 错误已交给回调记录，不继续消费成功结果。
  return
 }
 // 按 AST 顺序展示函数，避免 map 遍历顺序不稳定。
 for _, file := range files {
  for _, decl := range file.Decls {
   fn, ok := decl.(*ast.FuncDecl)
   if !ok { continue }
   obj := info.Defs[fn.Name]
   if obj == nil || obj.Pos() == token.NoPos { continue }
   // false 使用物理位置，不应用源码中 //line 的重映射。
   pos := fset.PositionFor(obj.Pos(), false)
   fmt.Printf("%s: %s:%d:%d\n", obj.Name(), pos.Filename, pos.Line, pos.Column)
  }
 }
}

Checker.Files 接收的是调用方准备好的 AST 文件列表。它不会替你扫描目录、筛选构建标签或决定哪些文件属于当前构建。两份 AST 的包归属和环境配置，应由上层加载逻辑确定。

对象位置和错误位置应该怎样解释

声明对象的 Pos() 返回声明位置，传给同轮 FileSet 的 PositionFor 后，才能形成可展示的文件位置。对于 types.Error，其 Fset 与 Pos 已经构成对应关系。记录诊断时，保留这一关系比只保存位置整数可靠。

Position 会考虑源码中的 //line 指令。示例使用 PositionFor(pos, false) 获取物理源码位置；需要逻辑文件名时可以使用调整后的位置。列号按字节计算，接入采用其他字符单位的编辑器协议时，应显式转换。

位置不属于当前 FileSet 时，File(pos) 返回 nil。另一份表如果恰好登记了相同数值区间，也可能把位置解释成无关文件，所以不能用“有行号”证明上下文正确。文件名也不是映射的替代物：同一 FileSet 允许多个文件记录采用相同名字，按文件名合并会丢失区别。

复用位置表与复用分析结果的区别

一次完整分析通常创建一次 FileSet，并贯穿解析、检查与诊断。长期运行的服务可以按工作区或源码快照管理它，但要明确旧 AST、位置表和类型信息的释放时机。持续向同一个位置表加入新文件，会保留相应的文件记录；这不等于已经实现增量分析缓存。

编辑源码后重新解析，会生成新的 AST。旧 AST 的位置不会自动跟随文本修改。Checker 能向同一个包增量添加文件，也不代表它会自动替换、删除或重新检查编辑过的声明。编辑器服务仍需单独制定快照和失效策略。

如果输入来自外部用户，诊断中的文件名应视作输入数据。服务可统一展示受控名称或相对路径，避免输出服务器路径；FileSet 不负责路径权限。这是展示层边界，不需要执行被分析程序来获取类型信息。

常见问题：能否新建一份同名文件表？不宜替换，保留原表更直接，也避免文件区间不同。能否多个包共享位置表？FileSet 可以覆盖多个文件，但 Package、Checker 和类型结果仍需按各自语义边界管理。是否一定更快？本文不作保证，位置一致性才是这里解决的问题。