Go 的 yacc 工具生成的解析器默认不暴露解析结果，直接访问内部栈（如 p.stack[1]）不可靠；推荐做法是在语法顶层规则中显式捕获最终 AST 节点，并通过 lexer 实例传递结果。
go 的 yacc 工具生成的解析器默认不暴露解析结果，直接访问内部栈（如 `p.stack[1]`）不可靠；推荐做法是在语法顶层规则中显式捕获最终 ast 节点，并通过 lexer 实例传递结果。
在使用 Go 自带的 yacc 工具（go tool yacc）构建语法解析器时，一个常见痛点是：生成的解析器（如 yyParse）执行完毕后，无法直接获取解析产生的抽象语法树（AST）节点。许多开发者尝试通过扩展生成的解析器结构体、直接读取内部栈（例如 p.stack[1].expr）来提取结果，但这是危险且不可靠的做法。
⚠️ 关键问题：stack 不是稳定接口
Go yacc 生成的解析器内部维护一个动态增长的 yystack，初始容量为 16。一旦归约过程导致栈扩容（例如复杂嵌套表达式），旧栈内存会被丢弃，新栈被分配并复制部分状态——而 yyParserImpl.stack[1] 指向的地址可能已失效或内容错位。正如 Go issue #16163 明确指出，该字段不属于公开 API，也不受兼容性保证，任何依赖它的代码都存在运行时崩溃或静默错误风险。
✅ 推荐方案：通过顶层语法规则 + lexer 状态传递结果
最符合 yacc 设计哲学、线程安全且可维护的方式，是将解析结果作为语法动作（action）的一部分，写入 lexer 实例的字段中。lexer 在 Go 中通常由用户自定义（如配合 nex 生成），天然适合作为解析上下文载体。
具体实现步骤如下：
-
为 lexer 类型添加结果字段（以 ShellLexer 为例）：
type ShellLexer struct { // ... 其他字段（如 input reader、token buffer 等） result *ShellProgram // ← 解析成功后的根 AST 节点 } -
在 .y 文件顶部声明类型别名与起始规则（确保 result 可被 $$.xxx 引用）：
%type <result> start %type <result> program</result></result>
%%
start : program { // 将归约得到的 $$（即 program 对应的 result）存入 lexer // 注意：shyylex 是 yacc 生成代码中对 lexer 的默认变量名， // 若你使用了 -p 前缀（如 -pyy），需相应改为 yyylex shyylex.(*ShellLexer).result = $$ }
3. **确保 `program` 规则正确设置 `$$`**（例如）：
```yacc
program : stmt_list {
$$ = &ShellProgram{Stmts: $1}
}
-
调用解析后，从 lexer 获取结果：
lexer := &ShellLexer{...} yyParse(lexer) // 或 yyParseWithPrefix(lexer) ast := lexer.result // ✅ 安全、明确、无副作用 if ast == nil { // 处理解析失败（如语法错误未被捕获） }
? 为什么这个方案更优？
- 解耦清晰：解析逻辑（yacc）与结果持有者（lexer）职责分离；
- 线程安全：每个 lexer 实例独立持有结果，支持并发解析不同输入；
- 无需修改生成代码：不侵入 yacc 输出，避免维护负担；
- 符合 LALR(1) 动作语义：$$ 是 yacc 标准机制，稳定可靠。
? 注意事项
- 若使用 nex 生成 lexer，确保其类型断言（shyylex.(*ShellLexer)）匹配实际 lexer 类型；
- shyylex 名称取决于 yacc 的 -p 参数（默认为 yy，故变量为 yyylex；若 -pyy 则为 yyylex；若 -psh 则为 shylex）；
- 建议在 start 规则后添加错误处理分支（如 | error { yyError("parse failed") }），并检查 lexer.result 是否为 nil 以区分语法错误与空输入。
综上，放弃对内部栈的“黑盒”访问，转而利用 yacc 动作语义与用户可控的 lexer 状态，是获取解析结果最稳健、最 Go-idiomatic 的方式。
