Go Expr 怎么编译一次表达式并重复求值

如果一条 Expr 表达式会被请求反复使用，直接在每次调用里写 expr.Eval，就会把解析和编译成本一起带进每次求值。更合适的做法是先调用一次 expr.Compile 得到程序，再把不同的环境交给 expr.Run。

官方地址：https://github.com/expr-lang/expr

固定表达式、变化数据的场景，按“编译一次、运行多次”组织：编译成功的程序进入缓存，后续请求只传入当前环境；表达式文本、环境契约或编译选项改变时再重新编译。

先看清 Eval 和 Compile/Run 的区别

Expr 暴露了两条使用路径。expr.Eval 适合一次性求值，它在内部完成解析、编译和运行；expr.Compile 返回一个可交给 expr.Run 的程序，适合相同表达式被重复调用的场景。

因此，性能问题不在于“Run 不能重复用”，而在于是否把 Compile 放进了高频循环。表达式本身不变时，把编译阶段前移，才能让每次请求只承担环境绑定和求值成本。

用环境契约编译一次表达式

编译时要让 Expr 知道表达式中变量的类型。可以用一个 Go 结构体作为 expr.Env，这样字段名和类型会参与检查；运行时再传入实际数据。下面的示例把环境定义和程序构建拆开，便于放进配置加载或缓存填充逻辑。

package main

import (
    "fmt"

    "github.com/expr-lang/expr"
    "github.com/expr-lang/expr/vm"
)

type RuleEnv struct {
    Level int
    Region string
}

func compileRule() (*vm.Program, error) {
    // 用零值结构体描述变量名和类型，不把某一次请求的数据带进编译阶段。
    return expr.Compile(`Level >= 3 && Region == "cn"`, expr.Env(RuleEnv{}))
}

func main() {
    program, err := compileRule()
    if err != nil {
        // 编译失败时不要把半成品程序放入缓存。
        panic(fmt.Errorf("编译规则失败: %w", err))
    }
    _ = program
}

这里显式使用 vm.Program 作为缓存对象类型，便于把“已编译程序”和“未编译文本”区分开。更直接的写法是把编译逻辑放在使用点，并只缓存编译成功的返回值。

编译错误应该在启动、配置刷新或缓存填充阶段暴露。例如变量名不存在、类型不匹配或表达式语法错误，都不应该等到第一条业务请求才发现。

同一个程序如何重复求值

编译完成后，运行阶段只替换环境。下面的代码使用一个明确的 RuleEnv，让同一个程序依次处理两组输入；表达式文本没有变化，也没有再次调用 Compile。

package main

import (
    "fmt"

    "github.com/expr-lang/expr"
)

type RuleEnv struct {
    Level int
    Region string
}

func main() {
    // 编译阶段只做一次，后面的输入共享同一份程序。
    program, err := expr.Compile(`Level >= 3 && Region == "cn"`, expr.Env(RuleEnv{}))
    if err != nil {
        panic(fmt.Errorf("编译规则失败: %w", err))
    }

    inputs := []RuleEnv{
        {Level: 4, Region: "cn"},
        {Level: 2, Region: "cn"},
    }
    for _, input := range inputs {
        // Run 只替换本次求值环境，不重新解析表达式。
        value, err := expr.Run(program, input)
        if err != nil {
            fmt.Printf("本次求值失败: %v\n", err)
            continue
        }
        fmt.Printf("允许=%v\n", value)
    }
}

服务代码可以把 program 放在只读配置对象、按表达式键索引的缓存或已构建的规则实例中。请求到达后准备好当前的 RuleEnv，调用 expr.Run 并处理返回值即可。

把编译错误和运行错误分开处理

两类错误的处理位置不同。编译错误说明表达式或环境契约不能建立，应该阻止缓存写入并反馈给配置发布者；运行错误只对应当前输入，例如环境值不完整或表达式执行阶段出现问题，通常应记录当前规则键和请求上下文，再决定是否拒绝当前请求。

不要在缓存函数里把错误打印后返回一个空程序，也不要把所有运行失败都当作“需要重新编译”。只有表达式、环境类型或编译选项变了，重新编译才有意义。

func buildProgram(source string) (any, error) {
    // 这里的错误属于编译阶段，调用方应在写入缓存前处理它。
    program, err := expr.Compile(source, expr.Env(RuleEnv{}))
    if err != nil {
        return nil, fmt.Errorf("规则不可用: %w", err)
    }
    return program, nil
}

func evaluate(program *vm.Program, input RuleEnv) (bool, error) {
    // 运行错误只影响当前输入，不负责修改程序缓存。
    value, err := expr.Run(program, input)
    if err != nil {
        return false, fmt.Errorf("规则求值失败: %w", err)
    }
    allowed, ok := value.(bool)
    if !ok {
        // 返回类型不符合业务约定时，显式拒绝而不是隐式转换。
        return false, fmt.Errorf("规则结果不是 bool")
    }
    return allowed, nil
}

示例中的 any 是为了突出错误边界，生产代码可以根据当前 Expr 版本的公开类型签名选择更具体的保存方式。无论采用哪种保存形式，都要保证同一个程序只和它编译时承诺的环境结构一起使用。

缓存键应该包含哪些信息

“编译一次”不等于“所有表达式共用一个程序”。至少要把表达式文本和会影响编译结果的契约放进缓存识别逻辑。若不同规则使用不同的变量集合、不同的自定义函数或不同的编译选项，就应当分开编译和保存。

如果规则来自配置中心，建议在配置版本切换时整体替换规则实例，而不是在请求线程中发现缓存不命中后临时修改共享对象。这样可以把编译成本和请求延迟隔离开，也更容易回滚有问题的规则。

常见问题

每次调用 expr.Run 都需要重新传入 expr.Env 吗？

不需要。expr.Env 是编译选项，用于描述环境；重复求值时传入与该契约匹配的实际环境即可。

表达式只改了一个常量，还能继续复用旧程序吗？

不能把它当作同一条规则。表达式文本已经变化，应按新的缓存键重新编译；只有运行时数据变化时才直接复用。

为什么不用 expr.Eval 写起来更短？

一次性脚本或低频调用用 Eval 很直观；同一表达式被大量重复使用时，Compile 加 Run 能把解析和编译从高频路径移出去。

小结

Go Expr 的重复求值可以收敛为三件事：用 expr.Env 描述编译时契约，用 expr.Compile 生成可复用程序，再用 expr.Run 绑定每次变化的环境。expr.Eval 适合一次性使用；对固定规则的服务路径，应把编译放在配置或缓存边界，并在表达式、类型契约和编译选项变化时重新建立程序。