Go parser.AllErrors 为什么仍不会返回每个语法错误

在编辑器或静态检查器里给 parser.ParseFile 加上 parser.AllErrors 后，最容易产生的误解是：既然名字叫“AllErrors”，返回值就应该覆盖源码里的每一个语法错误。实际并不是这样。这个标志只让解析器报告它在当前恢复路径上遇到的全部诊断，并取消默认的“同一行只留一条”和“错误过多就提前停止”限制；它不会穷举所有可能的错误。

AllErrors 保护的是已遇到的诊断，不是错误全集

Go 解析器默认会抑制与上一条诊断位于同一行的错误，因为这些消息很可能只是同一处语法破坏引起的噪声；错误数量超过十条后，默认模式还会停止继续解析。AllErrors 关闭的是这两层限制。因此它能让你看到更多已被解析器发现的消息，但不能改变解析器如何理解一段已经损坏的语法。

标准库源码把规则写得很直接：未设置 AllErrors 时，同一行的后续错误会被丢弃，累计超过十条后会触发停止；设置后这段抑制逻辑不再执行。这里没有“枚举源码中所有错误组合”的机制。

为什么明显写错的地方仍可能没有单独消息

语法错误会破坏后续 token 的上下文。递归下降解析器为了继续构造 AST，会寻找分号、右括号、声明起点等可同步位置；在找到同步点之前，它可能跨过一段无法可靠归属的源码。跨过的片段可能被表示为 ast.BadExpr、ast.BadStmt 或 ast.BadDecl，但不保证每个字符级问题都对应一条消息。

这会形成三类常见现象：

• 遮蔽：前面的缺失括号改变了后续结构，后面的错误暂时没有可判断的语法上下文。
• 合并：多个相邻 token 共同导致一次“期望某符号”的诊断，修好根因后才会暴露下一处问题。
• 级联：一处根因也可能产生多条衍生消息，所以“诊断条数”既不等于“独立错误数”，也不等于“修复次数”。

此外，go/parser 为了错误恢复会接受比 Go 规范稍宽的语言。例如某些结构会先进入 AST，是否真正合法要在后续检查阶段确认。因此仅靠语法诊断也不能覆盖声明、类型和包级约束。

完整读取 scanner.ErrorList，别只打印 err.Error()

ParseFile 的 error 动态值通常是 scanner.ErrorList。直接调用 err.Error() 时，多条错误会被压缩成“第一条以及还有若干条”的摘要。要展示已记录的每条诊断，应断言列表类型并逐项读取位置与消息。

package main

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

func main() {
	src := []byte(`package demo
func f() {
	var a =
	if true {
		println(a)
}`)

	fset := token.NewFileSet()
	// AllErrors 放宽报告限制；SkipObjectResolution 跳过已弃用的标识符解析阶段。
	file, err := parser.ParseFile(
		fset,
		"broken.go",
		src,
		parser.AllErrors|parser.SkipObjectResolution,
	)
	// 即使存在语法错误，也保留部分 AST 供编辑器或分析器做容错处理。
	fmt.Printf("partial AST available: %v\n", file != nil)

	if err == nil {
		fmt.Println("syntax accepted")
		return
	}
	list, ok := err.(scanner.ErrorList)
	if !ok {
		// 读取源码失败等情况不一定是语法错误列表。
		fmt.Println(err)
		return
	}
	for _, item := range list {
		// 分别读取文件、行、列和消息，避免只得到聚合摘要。
		fmt.Printf("%s:%d:%d: %s\n",
			item.Pos.Filename,
			item.Pos.Line,
			item.Pos.Column,
			item.Msg,
		)
	}
}

这个示例只说明读取方式，不预设固定诊断数量。解析器实现和错误恢复上下文可能改变具体消息；工具的稳定契约应是“读取有序列表”，而不是断言某份损坏源码永远产生 N 条错误。

先修靠前根因，再对新源码重新解析

如果目标是尽量找全独立问题，最有效的控制措施不是无限扩大单次诊断，而是迭代修复。先处理位置最靠前、结构影响最大的消息，例如包声明、引号、括号、花括号和复合字面量边界；然后对修改后的源码重新调用 ParseFile。上下文恢复后，原先被遮蔽的错误才可能出现。

工具链还要补上哪些检查

只解析单个文件时，AllErrors 仍然只覆盖语法解析阶段。若工具要判断一个包是否可用，还要把职责拆开：用 go/parser 取得容错 AST 与语法诊断，用 go/types 或 golang.org/x/tools/go/packages 处理类型、导入和包加载问题；多个文件则分别保留文件级诊断，不能让一个文件的摘要覆盖其他文件。

审计记录至少保留文件名、行列、消息、解析模式以及本轮源码版本。不要只存 err.Error() 的聚合文本，也不要承诺“0 条语法错误”等于“构建一定成功”。

验收时检查这六点

• 调用包含 parser.AllErrors，同时明确它只是报告模式。
• 把返回错误按 scanner.ErrorList 逐条消费，而不是只显示摘要。
• 允许 ast.File 为部分结果，并防御 ast.Bad* 与缺失节点。
• 不把诊断数量当作独立根因数量。
• 修复结构性首错后重新解析，而不是要求一次调用穷举。
• 需要包级正确性时，再接类型检查或包加载。

相关问题

AllErrors 会让 parser.ParseFile 返回 nil AST 吗？

源码已读入但存在语法错误时，文档说明通常会返回带 ast.Bad* 节点的部分 AST；读取源码本身失败时，AST 才可能是 nil。

为什么 err.Error() 只看到一条错误？

scanner.ErrorList.Error() 会把多条错误压缩成首条加剩余数量。断言为 scanner.ErrorList 后逐项遍历，或使用 scanner.PrintError。

DeclarationErrors 能代替 AllErrors 吗？

不能。它控制的是声明相关错误报告，AllErrors 控制默认错误抑制和提前停止；两者解决的边界不同。

语法检查通过后还需要 go/types 吗？

需要，前提是你的目标包含未定义标识符、赋值兼容性、接口实现或跨文件包关系。语法解析只负责形成 AST。

参考资料：https://pkg.go.dev/go/parser；https://go.dev/src/go/parser/parser.go；https://go.dev/src/go/scanner/errors.go。