17370845950

Go无官方解释器，go run是编译执行而非解释；其缺乏动态类型、eval等特性，故“解释器模式”需手动实现为解析+AST遍历+求值，如antonmedv/expr库提供实用方案。

Go 语言没有官方解释器，go run 是编译+执行的组合动作，并非边解析边执行的解释器。所谓“解释器模式”在 Go 中只能手动实现为**表达式解析 + AST 遍历 + 运行时求值**，不是语言特性，而是规则引擎的常见架构选择。

为什么 Go 不适合直接套用传统解释器模式

解释器模式（GoF）本质是把语法规则映射为对象树（AST），再递归解释执行。但 Go 缺乏动态类型、反射调用开销大、无 eval、不支持运行时加载未编译代码——这些都让“解释器”在 Go 里变成显式 parser + evaluator 的手工活。

• go eval 不存在；unsafe 或 plugin 无法加载任意字符串代码
• 用 reflect.Value.Call 调用函数需提前注册，不能动态解析 "user.Age > 18" 这类表达式
• 第三方库如 antonmedv/expr 或 mitchellh/go-homedir（误，应为 blevesearch/bleve 类似不相关）实际用的是自定义 lexer/parser，不是语言级解释器

用 antonmedv/expr 实现轻量规则引擎

这是目前 Go 生态最接近“解释器模式”的实用方案：它把字符串表达式编译成可复用的 expr.Program，再传入数据上下文执行，性能可控、语法简洁、支持函数扩展。

package main

import (
    "fmt"
    "github.com/antonmedv/expr"
    "github.com/antonmedv/expr/vm"
)

type User struct {
    Name  string
    Age   int
    Score float64
}

func main() {
    // 编译一次，多次执行
    program, err := expr.Compile(`Age > 18 && Score >= 90`, expr.Env(User{}))
    if err != nil {
        panic(err)
    }

    user := User{Name: "Alice", Age: 25, Score: 95.5}
    output, err := expr.Run(program, user)
    if err != nil {
        panic(err)
    }

    fmt.Println(output) // true
}

• 表达式必须提前 expr.Compile，不能每次 eval("...")
• expr.Env 告诉解析器变量结构体字段，不支持嵌套 map 动态访问（除非用 expr.AllowUndefinedVariables() + 自定义 Operator）
• 自定义函数需通过 expr.Function 注册，例如 "isAdult(Age)"，不能直接调用未声明函数

自己写 parser + visitor 的关键取舍点

当 expr 无法满足需求（比如需要访问 HTTP header、调用外部 API、审计日志埋点），就得手写解释器模式组件。核心不是“多像 Java”，而是控制权和可观测性。

• 词法分析建议用 goyacc 或 gocc 生成，别手写正则切分——规则变复杂后维护成本爆炸
• AST 节点设计要区分 *BinaryExpr、*CallExpr、*Ident，visitor 的 Visit 方法按类型 dispatch，别用 switch v.(type) 混合判断
• 上下文传参用结构体字段（如 ctx.Now time.Time、ctx.RequestID string），别依赖闭包或全局变量，否则并发不安全
• 错误位置必须返回原始表达式 offset，靠 lexer.Position 记录，否则规则报错时用户根本找不到哪错了

真正难的不是解析表达式，而是让规则变更能热加载、执行能限流、失败能降级、日志能追溯到具体哪条子表达式。这些和“解释器模式”名字无关，但决定了规则引擎能不能上生产。