Go scanner.End 为什么值得记录：语法工具的 token 结束位置校验

做 Go 源码索引、重命名提示或诊断高亮时，最容易出现的错位不是 token 起点，而是结束位置：界面多亮一列，或者切片少取一个字节。Go 1.27 给 go/scanner.Scanner 增加了 End，它返回“最后扫描 token 之后”的 token.Pos。因此，pkg 的起点是第 1 列，排他终点是第 4 列，而不是第 3 列。

Scanner.End 适合被当作 token 范围的排他右边界；真正转换成源码字节下标时，仍应交给对应的 token.File.Offset。

为什么源码工具总在 token 末尾多一列

很多工具会把 Scan 返回的 pos 保存下来，再用字面量长度推算结束位置。这对标识符看起来没问题，对运算符、注释、Unicode 内容和扫描器合成的 token 就不稳了。列号还是从 1 开始的显示坐标，不能直接拿来切字节数组。

下面的最小结构只观察一个标识符，故意把“起点”和“终点”分开：

src := []byte("pkg.Name")
fset := token.NewFileSet()
file := fset.AddFile("sample.go", fset.Base(), len(src))

var s scanner.Scanner
s.Init(file, src, nil, 0)
pos, tok, lit := s.Scan()
end := s.End()

fmt.Println(tok, lit)                   // IDENT pkg
fmt.Println(fset.Position(pos).Column) // 1
fmt.Println(fset.Position(end).Column) // 4

检查点很简单：pkg 占第 1、2、3 列，右边界落在第 4 列。若高亮逻辑把 4 当成最后一列，视觉上就会多出一个字符。

Scanner.End 的返回值到底落在哪里

官方文档把 End 定义为最后扫描 token 的后一个位置；如果还没有调用过 Scan，返回值是 token.NoPos。这两个状态要在工具代码里分开处理，不能把 NoPos 当成文件开头。

End 不是“扫描器当前字符”的公开游标，也不负责把位置变成行列文本。它只补上了一个此前需要调用方猜测的边界。行号、列号仍通过 token.FileSet 查询。

用源码范围替代手算偏移

当工具需要取出 token 原文或给诊断结果绑定源码时，先保留 pos 和 end，再让同一个 token.File 完成偏移转换：

start := file.Offset(pos)
stop := file.Offset(end)
if 0 

这里的区间是 [start, stop)：包含起点，不包含终点。这样既符合 Go 切片规则，也能让相邻 token 共用一个边界。Offset 还把位置坐标和文件基址的关系集中在 token.File 中，工具不必自己把行列号换算成字节数。

旧写法的问题不在列号而在职责边界

用 len(lit) 计算终点只对部分带字面量的 token 有效。标识符和数字通常有 lit，但标点的字面量可能为空；注释是否参与扫描取决于 scanner.ScanComments，换行还可能产生合成的分号。工具一旦把这些规则复制到自己的偏移函数里，就会出现两套词法边界。

更稳的职责划分是：Scanner.Scan 负责产生 token 与起点，Scanner.End 负责给出排他终点，token.File 负责位置到偏移的转换。诊断层只消费范围，不再猜测扫描器内部如何跳过空白或处理注释。

Go 1.27 之前的兼容边界怎么处理

Scanner.End 的文档标注为 Go 1.27.0 新增。如果源码分析工具仍要支持旧版本，不能只在本机升级 Go 后直接提交调用：旧工具链没有这个方法，CI 会在编译阶段失败。

优先方案是把工具的构建基线提升到 Go 1.27，并同步检查 go.mod、CI 镜像和发布说明。确实需要双版本时，可用构建标签隔离一个很薄的适配层；旧版本适配层应明确能力边界，不要用 len(lit) 冒充通用的 token 终点。只要项目依赖精确源码范围，升级构建链通常比维护第二套词法推断更便宜。

常见问题

Scanner.End 返回的是闭区间终点吗？

不是。它表示最后扫描 token 之后的位置，应作为半开区间的右边界使用。

还没调用 Scan 就调用 End 会怎样？

返回 token.NoPos。这表示没有扫描结果，不等于源码第一个位置。

可以直接用 fset.Position(end).Column 切 []byte 吗？

不可以。列号是显示坐标，切片前应使用对应 token.File 的 Offset。

采用这个 API 时，最值得留下的检查只有三项：起点来自同一次 Scan，终点来自紧随其后的 End，字节下标由同一个 token.File 转换。三者一致，token 高亮和诊断范围就不必再依赖手算偏移。