go标准库无内置eval，需用go/parser解析为AST后手动求值；须处理变量作用域、运行时类型转换与错误传播，统一返回interface{}+Error，并对数值运算建议转Float64兼容计算。
Go 语言标准库没有内置的表达式解释器，eval 类功能必须手动构建；直接用 go/parser + go/ast 解析后求值是可行路径，但需自行处理变量作用域、类型推导和操作符优先级——这不是语法解析问题，而是语义求值问题。
用 go/parser 解析字符串为 AST 节点
Go 的 go/parser 只能解析合法 Go 语法，且要求输入是完整声明或表达式（如不能直接解析 "a + b * 2"，除非包装成表达式语句）。常见错误是传入裸表达式导致 parser.ParseExpr 报 syntax error: unexpected $end。
- 正确做法：用
parser.ParseExpr("a + b * 2")—— 它支持纯表达式，但要求标识符不校验是否存在 - 若含变量（如
x > 5），AST 中对应节点是*ast.Ident，需在后续求值阶段查作用域 - 避免用
parser.ParseFile解析临时字符串，它强制要求文件头和 package 声明
手动实现 Eval 函数遍历 AST 求值
Go 没有反射式动态调用机制，所有节点类型必须显式 switch 处理。核心难点不是识别 + 或 ==，而是统一返回类型和错误传播——建议返回 Interface{} + error，并在顶层做类型断言。
-
*ast.BasicLit：根据kind（Token.INT/token.FLOAT/token.String）转成对应 Go 类型 -
*ast.BinaryExpr：先递归求值X和Y，再按Op（如token.ADD）执行运算；注意整数除零、浮点 NaN 等边界 -
*ast.ParenExpr：直接递归求值X，不改变语义 - 未处理节点（如
*ast.CallExpr）应明确返回fmt.Errorf("unsupported node type: %T", node)
func Eval(node ast.Node, scope map[string]interface{}) (interface{}, error) { switch n := node.(type) { case *ast.BasicLit: return strconv.ParseFloat(n.Value, 64) case *ast.Ident: if v, ok := scope[n.Name]; ok { return v, nil } return nil, fmt.Errorf("undefined identifier: %s", n.Name) case *ast.BinaryExpr: x, err := Eval(n.X, scope) if err != nil { return nil, err } y, err := Eval(n.Y, scope) if err != nil { return nil, err } return evalBinaryOp(n.Op, x, y) default: return nil, fmt.Errorf("unsupported node type: %T", node) } }变量作用域与类型混合带来的隐性陷阱
Go 是静态类型语言，但解释器运行时变量类型不确定。如果作用域中 "count" 有时是 int、有时是 float64，a + b 就无法在编译期校验——必须在 evalBinaryOp 中做运行时类型检查与转换，否则会 panic。
立即学习“go语言免费学习笔记（深入）”；
- 禁止直接用
int(x.(int)) + int(y.(int))：一旦y是float64，断言失败 - 推荐策略：对数值运算，统一转为
float64计算（兼容 int/float），字符串拼接单独分支处理 - 布尔表达式（
&&、||）必须确保左右操作数都是bool，否则提前返回类型错误 - 作用域嵌套（如 if 分支内新变量）需用栈式
map[string]interface{}，每次进入新块 push 新 map
真正难的不是解析出 AST，而是让 Eval 在任意用户输入下不 panic、不错值、不漏错——每种节点的 error 路径都要覆盖，每个类型转换都要有 fallback 或明确拒绝。