Go parser.ParseFile 怎样保留注释与文件位置信息

用 Go 做源码分析时，最容易遇到两个看似无关的症状：AST 里明明有声明，却找不到注释；节点已经拿到了，却无法稳定地还原到文件名、行号和列号。根因通常集中在三个参数：没有在 mode 中加入 parser.ParseComments，没有把同一个 token.FileSet 传给位置查询，或者解析出错后直接丢掉了返回的部分 AST。

正确的组合是：用 token.NewFileSet() 建立位置空间，把源码和文件名交给 parser.ParseFile，按需打开 parser.ParseComments，最后用 fset.Position(node.Pos()) 读取位置。下面只围绕这一条链路展开，不把它扩展成完整类型检查方案。

本文解决：源码分析程序怎样同时保留注释、节点位置和解析错误信息。

注释为什么会为空

parser.ParseFile 的 mode 默认并不会替你收集注释。注释要进入返回的 *ast.File，必须显式加入 parser.ParseComments。parser.SkipObjectResolution 则是另一个独立选择：它跳过已经弃用的标识符对象解析，不能用来代替注释开关。

同时，位置不是由 ast.File 自己凭空格式化出来的。解析时传入的 token.FileSet 记录文件和字节范围，节点的 Pos、注释的 Pos 再通过这个集合转换成 token.Position。少了同一个 FileSet，节点仍然可能存在，但回溯链条就断了。

用一段内存源码把三件事接起来

下面的例子不依赖磁盘文件，直接把源码放进 src。此时 filename 仍然值得填写：它不负责读取内容，但会成为位置和错误信息中的文件名标签。

package main

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

func main() {
	// FileSet 负责保存源码文件、字节偏移和行列位置的对应关系。
	fset := token.NewFileSet()
	src := []byte("package demo\n\n// 入口说明\nfunc Run() {}\n")

	// src 非空时由调用方提供源码；filename 仍用于位置和错误信息。
	file, err := parser.ParseFile(
		fset,
		"demo.go",
		src,
		parser.ParseComments|parser.SkipObjectResolution,
	)
	if err != nil {
		// 解析失败时不能只看 file 是否为空，还要保留具体错误。
		panic(err)
	}

	for _, group := range file.Comments {
		// Comment.Pos 必须用同一个 FileSet 转换，才能得到准确行列。
		pos := fset.Position(group.Pos())
		fmt.Printf("%s: %s\\n", pos, group.Text())
	}
	for _, decl := range file.Decls {
		// 声明节点与注释共享同一套位置空间，便于源码关联。
		fmt.Println("decl:", fset.Position(decl.Pos()))
	}
}

这里的关键不是把所有模式位都打开，而是按任务选择：要读注释就加入 ParseComments；不需要旧式对象解析时可以加入 SkipObjectResolution。file.Comments 与声明节点的 Pos 都通过同一个 fset 转换，才能在后续分析中对齐。

文件名、偏移和行列号不是一回事

当 src 是字符串或字节切片时，filename 只是位置标签；当 src 为 nil 时，解析器才会按文件名读取磁盘内容。这个区别很重要：内存扫描器可以使用稳定的虚拟名，例如 generated/config.go，但不能把它误解成已经读取了该路径。

token.Pos 更接近 FileSet 中的抽象位置，token.Position 才是人能读懂的文件名、行号、列号和偏移组合。不要把 Pos 当作全局字节下标保存到数据库；换了 FileSet 或合并了其他源文件后，它的解释环境就变了。

语法错误时怎样保留可用信息

解析器读到语法错误时，返回值不一定是“AST 或错误二选一”。源码已经读入但存在语法问题时，可能返回部分 *ast.File 和非空 error，错误中还可能包含按源码位置排序的多条诊断。源码读取失败时则应优先处理错误，不要把空 AST 当成正常结果。

因此源码分析工具要先保存两个返回值，再决定是否继续：需要展示错误位置时读取 error；需要尽量给编辑器或诊断器提供上下文时，可以在明确标记“部分 AST”的前提下消费 file。不能因为拿到了部分节点就把解析当成成功。

func parseForDiagnostics(src []byte) (*ast.File, error) {
	// 虚拟文件名让内存源码的错误位置仍然可读、可定位。
	fset := token.NewFileSet()
	file, err := parser.ParseFile(fset, "buffer.go", src, parser.ParseComments)
	if err != nil {
		// 部分 AST 只能用于诊断上下文，调用方仍需保留原始 error。
		return file, fmt.Errorf("parse buffer.go: %w", err)
	}
	return file, nil
}

上面的函数展示返回边界，实际工程中要补齐 go/ast 和 fmt 导入。重点是不要写成只返回 error 的黑盒：需要位置诊断的调用方应让 FileSet 和错误一起处在可追踪的生命周期内。

把问题固定成一张复查清单

• 注释为空：先检查 mode 是否包含 parser.ParseComments。
• 位置变成 1:1 或文件名不对：确认 filename 和传入的 FileSet 没有被替换。
• 节点能读但诊断丢失：检查是否忽略了 ParseFile 返回的 error。
• 部分 AST 被误当成成功：把“有返回节点”和“源码完整解析”分成两个状态。

最终可以把这条链路记成一句话：ParseComments 决定注释是否进入 AST，FileSet 决定位置如何解释，error 决定这棵 AST 是否完整。三者一起保留，源码分析工具才不会在最需要定位问题时失去上下文。

相关问题

内存源码的 filename 可以写空字符串吗？

可以作为输入，但不利于错误和位置输出。源码来自字符串或字节切片时，建议使用稳定的虚拟文件名，让诊断消息能直接指出来源。

只想读取 import，还需要完整解析吗？

不一定。可以按任务选择 parser.ImportsOnly 等模式；但如果还要注释和声明位置，就要确认模式不会提前截断你需要的 AST 信息。