Go Expr 怎样预编译表达式并复用程序对象

Go Expr 的预编译写法是：在规则加载时调用一次 expr.Compile，保存返回的 *vm.Program；每次求值调用 expr.Run(program, env)，传入当次输入。表达式和编译配置没有改变时，可以复用程序对象，不必在每条数据到来时重新编译。

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

下面讨论的是调用方式迁移：从逐次编译改为编译与运行分离，并非宣称某次版本升级新增了这项能力。规则以工单分流条件为例，重点是程序对象的生命周期与输入类型。

先把编译移出重复求值路径

重复处理相同规则时，编译放在循环内部会重复承担规则分析工作。迁移后，在加载配置或创建规则对象时完成编译，循环只负责运行和读取结果。

官方 入门文档明确建议编译一次、多次运行，并说明编译程序可并发使用。这里不提供“快多少倍”的结论，收益取决于规则复杂度、调用次数和宿主函数成本。

保持环境类型和编译配置一致

expr.Env(Input{}) 为编译器提供变量与类型信息，expr.AsBool() 要求规则结果适合作为布尔判断。它们是编译契约，不是本次业务数据。Input 中的 TicketCount、Region 和 Enabled 在每次 Run 时才取实际输入值。

本例的六个结构节点是 规则文本、Input类型、AsBool、Compile、Program、Run。规则文本、类型信息和结果要求与 Compile 关联，Compile 产生 Program，Run 使用 Program。

实际运行传入相同的环境类型。不要编译时用 Input 值，运行时随手改成 map 或另一个结构体；指针和值的形式也应保持一致。结构体字段标签、可用方法和 map 变量的类型规则见 环境文档。

用一个程序对象处理多组输入

下面将程序封装在 Rule 中。NewRule 只编译一次，Match 可被重复调用。示例不运行外部服务，没有实测输出；项目需要在 go.mod 中声明并固定 github.com/expr-lang/expr 的版本。

package main

import (
    "fmt"
    "log"

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

type Input struct {
    TicketCount int
    Region      string
    Enabled     bool
}

type Rule struct {
    program *vm.Program
}

func NewRule(source string) (*Rule, error) {
    // 空环境值用于声明类型，实际输入在运行时提供。
    program, err := expr.Compile(source, expr.Env(Input{}), expr.AsBool())
    if err != nil {
        return nil, fmt.Errorf("编译分流规则失败: %w", err)
    }
    return &Rule{program: program}, nil
}

func (r *Rule) Match(input Input) (bool, error) {
    if r == nil || r.program == nil {
        return false, fmt.Errorf("规则未初始化")
    }
    // 复用已有程序，但每次传入独立的输入值。
    output, err := expr.Run(r.program, input)
    if err != nil {
        return false, fmt.Errorf("执行分流规则失败: %w", err)
    }
    matched, ok := output.(bool)
    if !ok {
        return false, fmt.Errorf("规则结果应为布尔值，实际为%T", output)
    }
    return matched, nil
}

func main() {
    rule, err := NewRule("Enabled && TicketCount >= 6 && Region == 'east'")
    if err != nil {
        log.Print(err)
        return
    }

    inputs := []Input{
        {TicketCount: 8, Region: "east", Enabled: true},
        {TicketCount: 2, Region: "east", Enabled: true},
        {TicketCount: 9, Region: "west", Enabled: true},
    }
    for i, input := range inputs {
        matched, err := rule.Match(input)
        if err != nil {
            log.Printf("输入%d求值失败: %v", i, err)
            continue
        }
        log.Printf("输入%d是否命中: %t", i, matched)
    }
}

按表达式含义，三组输入分别对应命中、不命中、不命中，这是代码语义说明，不是运行记录。将 TicketCount 换成其他值，只改变求值输入；把阈值 6 改成 10 则改变了规则文本，需要重新编译。

保留 output.(bool) 的检查，能避免把运行接口返回的 any 直接当业务布尔值使用。编译成功也不等于所有运行输入都能成功，例如表达式调用的宿主函数仍可能返回错误。

共享程序时隔离可变环境

程序复用与数据共享要分别考虑：同一个 Program 可以用于多次 Run，但如果环境里放着被其他 goroutine 修改的 map、切片或指针，输入对象仍要遵守 Go 的并发访问规则。暴露给表达式的宿主函数也应自行保证并发安全。

第二张图以 Program、输入甲、输入乙、Run甲、Run乙、结果接收方 为节点。两个运行调用依赖相同程序，各自依赖不同输入，结果由调用方分别接收；图示没有要求启动并发。

不要因为程序可复用就主动修改它的字节码、常量或其他内部成员。通过公开的 Compile 和 Run 接口使用它，规则更新时生成新的对象，比原地改写旧程序更容易管理。

规则更新时替换完整程序对象

迁移到预编译后，新增的维护责任是“何时失效”。规则文本、环境结构、结果要求、自定义函数和编译选项都是程序语义的一部分。缓存键如果只放规则名称，就可能让新规则错误复用旧产物。

单条固定规则无需引入复杂缓存：启动时创建 Rule，之后复用即可。多租户或多版本规则可用规则版本与环境契约标识组织缓存，并给容量设上限。规则数量无限增长时，仅仅缓存 Compile 结果也可能积累过多内存。

如果运行中热更新，先完整编译候选规则，成功后再通过互斥锁或原子引用发布新 Rule；编译失败时按业务策略保留旧规则或拒绝更新。上述示例没有热更新入口，不能直接并发改写其中的 program 字段。

从旧调用方式迁移时，应保留同样的变量类型、函数集合和结果要求，再决定编译发生的位置。规则语义改变与调用开销优化分别记录，便于理解行为差异。编译配置文档列出了结果类型等选项。

输入数值变了，需要重新 Compile 吗？

规则和契约不变时，通常不需要。继续向 Run 传入新的 Input。若通过常量折叠或自定义编译选项把某些内容固化到产物中，则应按该配置的语义判断失效条件。

Compile 的 Env 是保存了请求参数吗？

本例使用 Input{} 表达类型，实际参数仍由 Run 提供。不要省略运行环境并期待编译器替你保存一份每次请求的业务状态。

程序能直接保存成跨版本通用文件吗？

本文复用的是进程中的程序对象，没有提供跨版本字节码持久化协议。需要重启后恢复规则时，保存规则文本与必要配置，启动后按固定依赖版本重新编译更清楚。