Go parser 错误中 expected token 怎么定位

Go 的 go/parser 报出 expected token 时，最有用的信息通常不是整段错误字符串，而是三个部分：expected 说明语法位置期待什么，found 说明当前实际读到了什么，token.Position 则把这个冲突落到文件、行号和列号。parser.ParseFile 还可能在发现语法错误后返回一个部分 AST，因此排查工具不应该只打印 err.Error() 就结束。

这篇只讨论 scanner.ErrorList、位置和错误恢复后的 AST，不涉及类型检查。官方文档入口：https://pkg.go.dev/go/parser#ParseFile。

expected 和 found 分别在说什么

可以先把常见消息读成一句话：“解析器在这个位置需要 A，但当前 token 是 B”。例如 expected ')', found '{'，重点不是花括号本身一定写错，而是前面的参数、条件或表达式很可能没有闭合。解析器的错误位置通常指向当前违规 token 的起始处；真正遗漏的字符可能在它前面。

found 也可能是换行。Go 的扫描器会把换行转换成隐式分号，因而有些消息会显示 found newline。看到这类提示，应优先检查上一行是否少了逗号、右括号或运算符，而不是机械地在报错列插入字符。

Go 源码中的 errorExpected 会把期望内容组合进消息；当当前位置就是当前 token 时，还会补充实际字面量或 token 名称。所以排查顺序应是：先看 found，再向前回看一个语法单元，最后才判断 expected 应该怎样补齐。

用 ErrorList 把报错落到源码行列

下面的写法保留每一条错误的结构化位置。parser.AllErrors 允许解析器尽量收集更多语法错误，parser.SkipObjectResolution 则跳过已经不推荐依赖的对象解析字段。

package main

import (
	"errors"
	"fmt"
	"go/ast"
	"go/parser"
	"go/scanner"
	"go/token"
)

func main() {
	// 故意遗漏函数参数列表的右括号，观察 expected/found 的位置关系。
	src := `package demo

func greet(name string {
	return name
}`

	fset := token.NewFileSet() // FileSet 负责把 token.Pos 映射成文件、行、列。
	file, err := parser.ParseFile(fset, "demo.go", src, parser.AllErrors|parser.SkipObjectResolution)
	if err != nil {
		var list scanner.ErrorList
		if errors.As(err, &list) {
			for _, item := range list {
				// Pos 是错误 token 的起始位置，Msg 保留 expected/found 原文。
				fmt.Printf("%s:%d:%d: %s\n", item.Pos.Filename, item.Pos.Line, item.Pos.Column, item.Msg)
			}
		} else {
			fmt.Println("解析失败：", err)
		}
	}

	if file != nil {
		bad := 0
		// 部分 AST 可以遍历，但 Bad* 节点代表语法恢复占位，不宜当成完整代码。
		ast.Inspect(file, func(n ast.Node) bool {
			switch n.(type) {
			case *ast.BadExpr, *ast.BadStmt, *ast.BadDecl:
				bad++
			}
			return true
		})
		fmt.Println("部分 AST 已返回，错误占位节点：", bad)
	}
}

这里的关键是不要把 scanner.ErrorList 降级成字符串。item.Pos.Line 与 item.Pos.Column 能直接定位阅读范围；如果只需要最终错误，也可以调用 list.Err()，但会失去逐条处理的机会。

有语法错误时，部分 AST 能不能继续用

能，但要把它当作“恢复后的结构”而不是已经通过语法检查的完整程序。官方 ParseFile 文档说明：源码可读但存在语法错误时，返回值可能是部分 *ast.File，错误片段用 ast.Bad* 节点表示；多条错误通过按源码位置排序的 scanner.ErrorList 返回。

因此可以用部分 AST 做编辑器提示、错误附近的结构分析或增量工具，但不要在 err != nil 时继续执行依赖完整声明、类型信息或对象绑定的业务逻辑。遍历时把 *ast.BadExpr、*ast.BadStmt 和 *ast.BadDecl 单独计数，能快速判断恢复范围是否已经影响到后续节点。

如果是文件读取失败而不是语法错误，file 可能为 nil。这也是为什么代码先处理错误，再单独判断 file != nil，不能把“有 AST”当成“没有问题”。

按行列回看时，优先检查这四个位置

1. 当前列：确认 found 指向的 token 是否真的是不合法字符，还是前面缺少闭合符号导致解析器在此处才发现矛盾。
2. 上一行末尾：重点看逗号、右括号、右方括号和运算符。换行可能触发隐式分号，错误看起来就像发生在下一行。
3. 最近的同层分隔符：从报错列向左匹配 ()、[]、{}，优先修复最早失配的那一组，而不是批量删除后续错误。
4. 后续错误：先修第一条位置靠前的错误，再重新解析。错误恢复会跳过或生成占位节点，后面的 expected token 可能只是连带结果。

如果要做编辑器或批量检查器，建议同时保留原始源码、FileSet 和 ErrorList，把错误附近的原文片段交给上层展示。这样既能显示“第几行第几列”，也能保留解析器给出的语法上下文。

常见追问

expected token 指的是缺少的字符吗？

不一定。它表示解析器在当前语法位置期待的 token；真正缺少的字符可能位于当前 found token 之前，尤其是括号、逗号和表达式运算符。

ParseFile 返回 AST 后还需要处理 err 吗？

需要。AST 非空只说明解析器恢复出了一部分结构，不能替代对 ErrorList 的处理。只有在明确接受不完整语法的工具场景中，才继续消费并识别 ast.Bad* 节点。

把 expected、found、位置和 AST 分开看，Go parser 的报错就从一句模糊提示变成了可操作的定位信息：先修最靠前的结构错误，再重新解析，最后才依据完整 AST 做后续分析。