Go FileSet.AddFile 为什么不能随意复用旧 base

我第一次手写 go/token.FileSet 时，把第二个文件的 base 继续写成了第一个文件的起点。代码看起来像是在“复用同一套坐标”，结果却把两个文件映射进了同一个位置区间。处理多个源码文件时，base 不是文件名的别名，而是 Pos 在整个 FileSet 中的起点；每个新文件都必须从当前可用的边界继续分配。

为什么旧 base 会让文件区间重叠

FileSet 把每个文件的字节位置映射为一个独立区间。假设第一个文件使用 base=1、size=10，它占用的范围就是 [1,11]，下一个安全起点至少是 12。如果第二个文件仍传 1，它的区间就会回到旧文件上，FileSet 无法再根据一个 Pos 唯一判断所属文件。

当前 Go 实现会检查 base ，并以 invalid base 触发 panic；这不是提示你换一个更大的随机数，而是说明分配策略破坏了位置空间。源码中的 +1 也很关键：EOF 自身占一个位置，所以新边界是 base + size + 1。

File.Base、FileSet.Base 和 offset 不是一回事

排查这类问题时，我会先把三个概念分开。File.Base() 是某个文件注册时的起点；FileSet.Base() 是向下一个 AddFile 提供的最小安全 base；offset 则是文件内部从 0 开始的字节偏移。第一个文件的 base=100、size=4 时，文件内部 offset 仍然从 0 到 4，不应把 100 当成业务数据的行号或列号。

连续加入文件时怎样选择安全 base

最稳的写法是让 FileSet 自己提供边界。下面的示例还演示了负 base 的特殊含义：传入负数时，AddFile 会采用当前 FileSet.Base()，但团队代码里我更偏向显式写出 fset.Base()，因为读者一眼就能看到坐标来源。

package main

import "go/token"

func addSources() {
	set := token.NewFileSet()

	// size 是源码字节数；第一个文件可以从一个明确的起点开始。
	first := set.AddFile("main.go", 1, 24)

	// 第二个文件必须从 FileSet.Base() 之后开始，避免 Pos 区间重叠。
	second := set.AddFile("util.go", set.Base(), 16)

	// 文件内 offset 交给 File.Pos 转换，不要手动加 base。
	_ = first.Pos(7)
	_ = second.Pos(3)
}

若确实要封装添加逻辑，可以把 base 固定为 -1，但要在注释里说明这是 API 的“使用当前边界”约定。不要在循环外缓存一个旧 base；文件大小变化、插入新文件或恢复序列化数据后，它都可能已经过时。

位置转换和边界排查清单

拿到一个 Pos 后，用 set.Position(pos) 还原文件名、字节偏移和行列信息。不要把不同文件的 Pos 直接当作同一文件 offset 比较；跨文件比较反映的是它们在 FileSet 中的加入顺序和区间位置。

func locate(set *token.FileSet, file *token.File, offset int) token.Position {
	// 先由当前文件把内部字节偏移转为 Pos，再交给 FileSet 定位。
	pos := file.Pos(offset)
	// Position 负责把全局 Pos 还原为文件名、行号和列号。
	return set.Position(pos)
}

实际排查可按四项确认：size 是否为非负字节数；是否每次都重新读取 FileSet.Base()；是否把 offset 错当成 base；是否在多个 FileSet 之间混用了不属于当前集合的 Pos。如果长期服务不断加入文件，还可以在确认文件不再需要后调用 RemoveFile 回收位置树占用，但这不等于可以复用旧 base 来覆盖新文件。

常见问题

负数 base 是不是任何时候都安全

它只表示“采用当前 FileSet.Base()”，不能修复负的 size，也不能让一个已经属于其他集合的 Pos 变得有效。

两个文件可以使用同一个文件名吗

可以，AddFile 允许文件名重复；真正不能重复的是会重叠的位置区间。

删除文件后能不能回收它的 base

RemoveFile 会让后续查询不再命中该文件并减少内存占用，但新的文件仍应从当前边界分配，不要回到旧区间。