Go template/parse.Tree 怎么检查模板节点：ActionNode、Pipeline 与语法错误位置

模板上线前，最难排查的往往不是渲染结果，而是“某个字段突然不见了”或“模板配置一保存就报错”。这类问题可以提前放到编译前检查：用 text/template/parse 把模板变成语法树，确认 ActionNode 和 PipeNode 是否出现在预期位置，同时把非法模板的错误位置留在日志里。

如果目标是做静态检查，优先检查 parse.Tree.Root 下的真实节点类型；ActionNode.Pipe 负责承接动作表达式，解析失败则直接使用返回的错误文本定位模板边界。

先看一份能运行的模板树

下面的示例只依赖标准库。模板文本固定为“订单号”和“用户姓名”两个字段，程序先解析，再从 Root 开始递归打印节点。文章中的终端截图就是这份程序的实际运行结果。

valid, err := parse.Parse("invoice", "订单号={{.ID}} / 用户={{.User.Name}}", "", "", nil)
if err != nil {
    panic(err)
}
root := valid["invoice"].Root
walk(root, 0)

输出里最值得核对的不是缩进，而是节点顺序：文本节点先出现，接着是动作节点；动作节点下面能看到 PipeNode，它再包含字段访问的命令节点。

ActionNode 和 Pipeline 应该怎么检查

ActionNode 表示 {{...}} 中的一次动作，ActionNode.Pipe 是它的管道表达式。做模板白名单检查时，可以在递归遇到动作节点后读取 Pipe.Cmds，判断调用了哪些字段或函数；不要把整段 String() 当成结构化数据。

if action, ok := n.(*parse.ActionNode); ok {
    pipe := action.Pipe
    for _, command := range pipe.Cmds {
        fmt.Printf("command=%T text=%q\n", command, command.String())
    }
}

这个检查适合放在模板加载阶段，例如限制邮件模板只能读取 ID、User.Name 等字段。它能告诉你“树里出现了什么”，但不能代替执行阶段的真实数据校验；字段值是否为空，仍然要在渲染测试中确认。

解析错误要在加载阶段截住

模板少一个右花括号时，parse.Parse 不会返回一棵“勉强可用”的树，而是直接返回错误。示例把 {{.ID 作为坏模板输入，并把错误原文打印出来，方便日志或测试断言使用。

_, err = parse.Parse("broken", "订单号={{.ID", "", "", nil)
fmt.Printf("[invalid] parse error: %v\n", err)

截图中的错误位置是模板加载阶段的证据。生产代码可以把模板名、版本号和错误文本写入启动检查日志，然后让服务不进入接收请求状态；不要等到第一封邮件或第一张页面渲染时才发现语法损坏。

相关问题：树检查不等于数据检查

只看模板字符串能判断字段是否存在吗？

不能。字符串只能证明文本里写了什么；节点遍历能证明解析器识别了什么，字段最终能否从数据对象取到，还要配合一次真实执行测试。

为什么不直接用正则匹配 {{...}}？

正则很容易漏掉嵌套管道、注释和字符串边界。标准库已经给出了语法树，检查节点类型和 PipeNode 更容易写出可维护的规则。

解析失败后还能拿到部分 Root 吗？

不要依赖部分结果。把 err 当成硬门槛，只有错误为空时才保存并使用返回的树映射。

上线前的最小检查清单

• 模板加载时检查 err，记录模板名和可定位的错误文本。
• 从 Tree.Root 递归，明确处理 ListNode 和 ActionNode。
• 对动作读取 ActionNode.Pipe，按实际需求核对字段或函数。
• 至少准备一份合法模板和一份缺失分隔符的坏模板测试。

text/template/parse 的价值在于把“模板看起来像对的”变成可检查的节点证据。先在加载阶段拿到稳定的树，再在执行测试里验证数据，两层检查分开，模板问题就不会和业务数据问题混在一起。