Go token.FileSet.RemoveFile 后旧位置为什么无法定位

Go 的 token.FileSet.RemoveFile 让旧位置“无法定位”，通常是因为把两种查询混在了一起：FileSet 负责从全局 token.Pos 找文件和位置，*token.File 负责在已知文件内做偏移换算。RemoveFile 移除的是前一种索引关系，不是把你手里保存的 *token.File 自动变成无效指针。

官方资料：https://pkg.go.dev/go/token#FileSet.RemoveFile

先确认 RemoveFile 改变的是哪一层

token.Pos 是一个文件集合范围内的紧凑位置值。文件加入 FileSet 时会占用一个不重叠的区间，FileSet.File(p) 再根据这个区间找回文件。官方文档对 RemoveFile 的定义很明确：移除文件后，该文件 Pos 区间的后续查询会得到负结果，主要用于处理长期运行且不断遇到新文件的 FileSet，减少内存占用。

所以它影响的是“集合是否还索引这个文件”。如果业务代码另外保存了 file := fset.AddFile(...) 返回的指针，这个变量不会因为从集合移除而自动变成 nil。两者可以先这样理解：FileSet 是全局定位目录，File 是某个文件自身的坐标换算器。

分开观察 FileSet.File 和 FileSet.Position

排查“旧位置为什么找不到”时，先保留一个属于旧文件的 Pos，分别观察移除前后的集合级查询。下面的示例故意把集合查询和文件级查询写在不同位置，避免把结果误判成一个 API 的问题：

package main

import (
	"fmt"
	"go/token"
)

func main() {
	fset := token.NewFileSet()
	fileA := fset.AddFile("a.go", -1, 12)
	fileB := fset.AddFile("b.go", -1, 8)

	// 先从 fileA 的文件内偏移构造一个属于 fileA 的全局 Pos。
	p := fileA.Pos(4)
	fmt.Printf("before: file=%s position=%s\n", fset.File(p).Name(), fset.Position(p))

	// RemoveFile 只撤销 fileA 在 fset 中的区间索引；fileB 仍属于 fset。
	fset.RemoveFile(fileA)

	// 集合级查询已经找不到 p 对应的文件，Position 也不再提供旧文件位置。
	fmt.Printf("after: file=%v position=%v\n", fset.File(p), fset.Position(p))
	fmt.Printf("other file still indexed: %s\n", fset.File(fileB.Pos(2)).Name())
}

移除前，fset.File(p) 能返回 fileA，fset.Position(p) 能把它转成文件名、行号和列号。移除后，集合不再承认这个 Pos 属于它的某个文件，因此 File 查询为 nil，位置查询得到无效的零值语义。fileB 的区间没有受影响。

这里的关键不是 Pos 的整数值被改写了，而是“这个值能否通过当前 FileSet 反查到文件”发生了变化。

保留 File 级换算所需的信息

如果业务还需要把旧文件中的某个偏移转成行列，应该在生命周期设计中保留必要的 *token.File 或提前保存业务结果。File.Position(p) 是文件对象自己的方法，不需要再让 FileSet 通过区间查找一次。

package main

import (
	"fmt"
	"go/token"
)

func main() {
	fset := token.NewFileSet()
	file := fset.AddFile("stream.go", -1, 20)
	p := file.Pos(7)

	// 先设置行起点，便于把文件内偏移换算成更有用的行列信息。
	file.SetLines([]int{0, 5, 12})

	// 释放 FileSet 的集合级索引，但保留 file 供当前任务完成诊断。
	fset.RemoveFile(file)

	// 文件级方法直接使用 file 的坐标规则，不依赖 fset.File(p)。
	position := file.Position(p)
	offset := file.Offset(p)
	fmt.Printf("name=%s line=%d column=%d offset=%d\n", position.Filename, position.Line, position.Column, offset)
}

这个写法适合“解析完一个文件后，集合不再负责全局反查，但当前任务还要生成诊断”的场景。注意，file.Position(p) 要求 p 是这个文件中的位置，或者是 token.NoPos；不能拿另一个文件的 Pos 冒充。

把 RemoveFile 放进流式处理生命周期

在持续扫描源码、模板或生成文件的程序里，常见的生命周期可以分成四步：

1. 加入并解析：把文件加入 FileSet，让解析器和 AST 使用统一的 Pos。
2. 提取业务信息：把错误位置转换为文件名、行列、范围或自定义诊断对象；如果后续还要做文件内换算，保留对应的 *token.File。
3. 结束集合级工作：确认不会再通过该 FileSet 反查旧文件后调用 RemoveFile。
4. 结束文件级工作：业务诊断完成后再释放自己保存的引用。

“先提取，再移除”比“发现旧文件不用了就立即移除”更稳妥，因为 AST 节点或诊断队列里可能还保存着这个文件的 Pos。移除并不会让这些整数位置自动变成可跨集合使用的全局 ID；如果需要长期保存，保存最终的文件名、行列和范围通常更清楚。

避开几个容易混淆的边界

总结

遇到“Go token.FileSet.RemoveFile 后旧位置无法定位”，先问自己调用的是哪一层：需要从 Pos 反查文件时，走的是 FileSet，移除后结果自然会消失；已经知道具体文件、只需要换算偏移时，走的是 *token.File，只要引用和位置规则仍在，就可以继续完成文件级工作。

因此，流式解析器的安全顺序是：先把需要长期使用的诊断信息落地，再移除旧文件的 FileSet 索引，最后释放文件级引用。这样既能控制长期内存，又不会把“集合不再定位”误解为“所有旧位置数据都被抹掉”。