当前位置：首页 > 文章列表 > Golang > Go问答 > Go parser 错误中 expected token 怎么定位

Go parser 错误中 expected token 怎么定位

来源：17golang原创 2026-11-14 16:59:32 0浏览收藏

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。看到这类提示，应优先检查上一行是否少了逗号、右括号或运算符，而不是机械地在报错列插入字符。

parser.ParseFile、token.FileSet、scanner.Scanner 与 expected token、found token、scanner.ErrorList 的静态关系说明图 — 图1：静态结构说明图，查看 expected token、found token 与 ErrorList 的关系；它不是运行截图。

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 返回。

parser.ParseFile 返回 scanner.ErrorList、部分 ast.File 与 ast.BadExpr、ast.BadStmt、ast.Inspect 的静态关系说明图 — 图2：静态结构说明图，查看部分 AST 与 ast.Bad* 占位节点的关系；它不是运行结果截图。

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

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