Go CEL 的常量子表达式怎样通过 OptOptimize 复用计算

我第一次把 CEL 放进 Go 服务时，真正影响延迟的不是表达式写得长，而是把同一段表达式连同固定配置反复编译了。解决这类问题的关键是：把表达式编译成一个可复用的 cel.Program，在创建 Program 时加上 cel.EvalOptions(cel.OptOptimize)。CEL-Go 会在 Program 创建阶段预计算“参数由常量组成”的函数或运算；后续每次 Eval 只替换输入变量。

官方地址：https://pkg.go.dev/cel.dev/cel-go/cel

OptOptimize 复用的是 Program 创建时已经确定的优化结果，不是把任意运行时输入缓存起来。固定子表达式适合提前算，依赖请求变量的部分仍然要在 Eval 时计算。

先划清：什么叫“常量子表达式”

可以把一条 CEL 表达式拆成两类。第一类只依赖字面量、固定的函数参数或固定配置，例如字符串拼接、固定正则模式、固定集合构造；第二类依赖 x、request 这类每次请求都可能改变的变量。OptOptimize 的价值在于处理第一类，不能把第二类误认为编译期常量。

下面这个例子故意让正则模式固定、待匹配字符串动态。这样优化边界很清楚：正则相关的准备工作属于固定部分，x 仍然来自每次求值的 activation。

package main

import (
    "fmt"

    "cel.dev/cel-go/cel"
)

func main() {
    env, err := cel.NewEnv(
        // 只把每次请求都会变化的字符串声明为变量。
        cel.Variable("x", cel.StringType),
    )
    if err != nil {
        panic(err)
    }

    ast, issues := env.Compile(`x.matches('^go-[0-9]+$')`)
    if issues.Err() != nil {
        // 编译失败应在加载配置时暴露，而不是拖到请求期间。
        panic(issues.Err())
    }

    program, err := env.Program(ast, cel.EvalOptions(cel.OptOptimize))
    if err != nil {
        // OptOptimize 相关的构建问题也应阻止无效 Program 进入服务。
        panic(err)
    }

    for _, input := range []string{"go-17", "rust-1"} {
        out, _, err := program.Eval(map[string]any{"x": input})
        if err != nil {
            // 每次 Eval 只提供动态变量，固定正则无需重新准备。
            fmt.Println("eval error:", err)
            continue
        }
        fmt.Println(input, out.Value())
    }
}

完整流程：把优化放在 Program 创建处

这条链路里，env.Compile 负责解析和类型检查，env.Program 负责把检查后的 AST 变成可执行程序。OptOptimize 是 Program 选项，因此应该和 Program 一起配置，而不是每次 Eval 时临时决定。

我在服务里会把这一步放在初始化或配置热加载阶段：表达式不变时只创建一次 Program，处理请求时复用它。官方示例也把 cel.OptOptimize 传给 env.Program，然后用不同输入反复求值；这正是“固定部分提前处理、变化部分留到 Eval”的使用方式。

阶段拆解：哪些子表达式能被提前计算

判断能否复用时，可以问一个很实用的问题：如果把所有输入变量暂时拿走，这一段是否仍然有确定结果？如果答案是“是”，它通常具备常量折叠的条件；如果答案是“否”，就应保留到运行时。

这里的“复用”不是把上一次请求的结果拿给下一次请求，而是复用同一个 Program 以及它在创建阶段已经准备好的固定部分。不同输入仍然可能得到不同结果，也仍然可能产生运行时错误。

推荐流程：编译一次，安全地复用多次

一个可复用的落地顺序是：启动时创建 Env，加载表达式并检查错误；用 OptOptimize 创建 Program；把 Program 放到只读配置或服务对象中；请求到来时只构造本次 activation。CEL 的 Program 求值是线程安全且无副作用的，适合多个输入共享同一实例，但前提是你没有把会变化的业务值硬编码进表达式。

import (
    "fmt"

    "cel.dev/cel-go/cel"
)

type Matcher struct {
    // Program 在初始化后只读，所有请求共享这份已编译结果。
    program cel.Program
}

func (m Matcher) Match(value string) (bool, error) {
    // activation 只装入请求级变量，不能复用上一请求的 map。
    out, _, err := m.program.Eval(map[string]any{"x": value})
    if err != nil {
        return false, err
    }
    matched, ok := out.Value().(bool)
    if !ok {
        // 结果类型异常时显式返回，避免把动态值静默当成 false。
        return false, fmt.Errorf("unexpected CEL result: %T", out.Value())
    }
    return matched, nil
}

如果表达式还包含自定义函数，要特别留意函数绑定是否真的适合在 Program 创建阶段调用。固定参数的纯函数更容易被提前处理；依赖请求状态、外部 IO 或隐含副作用的函数，不应为了“优化”而假设它能被安全折叠。

常见误区：OptOptimize 不等于万能缓存

• 每次请求重新 Compile：即使打开 OptOptimize，也抵消了 Program 复用的收益；把编译放到初始化或明确的热加载路径。
• 把变量当常量：x + 1 中的 1 可以固定，但整体结果依赖 x，不能预先得到最终值。
• 忽略版本和导入路径：当前 cel-go 的官方文档说明，cel.dev/cel-go 是较新的规范导入路径，旧的 github.com/google/cel-go 文档主要用于兼容版本；升级时应按项目实际版本核对 API。
• 把性能结论写死：是否更快要结合表达式复杂度、输入规模和函数绑定做基准测试，OptOptimize 本身不是性能保证书。

速查表：什么时候该用哪种方式

相关问答

OptOptimize 会缓存每个输入的结果吗？

不会。它主要在 Program 创建时处理常量参数和可提前准备的运算；每次 Eval 仍根据当前 activation 计算动态部分。

为什么打开优化后结果没有变化？

优化通常不改变表达式语义，只减少固定部分的重复工作。表达式很短、固定部分很少时，结果相同且性能差异不明显是正常的。

OptOptimize 和 OptPartialEval 有什么区别？

OptOptimize 面向 Program 创建阶段的常量优化；OptPartialEval 配合部分变量输入，关注哪些属性未知以及如何保留残余表达式，两者解决的问题不同。