Go CEL 环境扩展后为什么要重新检查表达式

Go CEL 扩展环境后，原有表达式的检查结果不会自动获得新增声明、函数重载或目标环境的类型判断。准备把规则交给新环境使用时，应在目标环境重新调用 Compile，或在适用场景中重新执行 Check，再用对应环境构建 Program。仅仅调用 Extend，不能证明某份旧 AST 已经按新环境检查过。

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

CEL-Go 当前官方仓库采用 cel.dev/cel-go 导入路径；原 google/cel-go 仓库已说明其兼容用途。下面以新增库存预留变量为例，讨论环境扩展与规则产物的关系，不把这个 API 行为包装成某次新版本公告。

扩展环境不会改写已有检查结果

设想库存规则原来只有 stock > 0，环境只声明 stock。后来业务增加 reserved，希望规则改为 stock - reserved > 0。新增一个输入 map 键还不够：规则的静态声明、表达式检查产物和求值输入要共同描述这次变化。

环境提供表达式可见的名字、类型、函数和其他配置。Checked AST 保存的是一次检查所得到的类型与引用信息。Program 又是根据 AST 和构建选项准备的求值对象。它们彼此相关，却不是同一个会被 Extend 统一更新的对象。

区分 Extend、Check 和 Compile 的职责

如果变化涉及宏或解析配置，从原始规则文本重新 Compile 更容易保持完整语义。只拿解析后的 AST 重新 Check，不应被当作重做所有解析行为的替代方案。保留源码的价值，就在于环境迁移时仍能从明确的输入重新生成产物。

新增变量后，在返回的新环境编译规则

下面是一段完整集成示例。它保留 Extend 返回的 target，在 target 中编译带 reserved 的新规则，并明确处理环境构造、规则编译、程序构建和求值错误。代码用于读者自行复现，文中没有把它描述成已执行的线上结果。

package main

import (
    "fmt"
    "log"

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

func main() {
    // 基础环境只声明商品库存。
    base, err := cel.NewEnv(cel.Variable("stock", cel.IntType))
    if err != nil {
        log.Fatal(err)
    }
    // Extend 返回新环境；保留返回值供后面的规则编译使用。
    target, err := base.Extend(cel.Variable("reserved", cel.IntType))
    if err != nil {
        log.Fatal(err)
    }

    source := "stock - reserved > 0"
    // Compile 同时解析和检查，使新增变量参与本次类型检查。
    ast, issues := target.Compile(source)
    if issues != nil && issues.Err() != nil {
        log.Fatalf("目标环境编译失败: %v", issues.Err())
    }
    if ast == nil || !ast.IsChecked() {
        log.Fatal("没有取得已检查的表达式")
    }
    // 本场景要求库存判断必须返回布尔值。
    if ast.OutputType() != cel.BoolType {
        log.Fatal("规则必须返回 bool")
    }
    program, err := target.Program(ast)
    if err != nil {
        log.Fatalf("程序构建失败: %v", err)
    }
    // 输入与声明保持一致；CEL int 在此使用 Go int64。
    out, _, err := program.Eval(map[string]any{
        "stock": int64(12),
        "reserved": int64(4),
    })
    if err != nil {
        log.Fatalf("规则求值失败: %v", err)
    }
    fmt.Println(out)
}

这个示例中的表达式按给定数值应为真，这是规则本身的算术含义，不是本次实测日志。实际应用还要定义库存和预留量允许的范围；“返回 bool”只能约束结果类型，不能替代领域规则。

如果丢弃 Extend 的返回值，继续用 base 编译新的表达式，reserved 仍不属于那个基础环境的声明集合。相反，若只是给 Eval 的输入多塞一个 reserved，也不会把旧规则自动改成扣除预留库存的规则。

纯新增声明不代表旧规则必然失效

标题中的“重新检查”应理解为采用新环境时的一种明确兼容确认，而不是说所有扩展都会破坏已有规则。假设旧规则只引用 stock，新环境只是额外声明 reserved，并未改变旧规则相关能力，那么旧规则可能仍然适用。它不会因为新增了一个未使用的名字就必然报错，也不会自动开始引用这个名字。

需要收紧的是另外一种推断：旧产物曾经检查通过，所以它已被新环境认可。特别是函数库、名字解析、类型提供器或构建选项一并变化时，不能只看旧的 IsChecked 标志，就把目标环境的兼容性当作已经完成。这个标志描述 AST 的检查状态，不是跨环境兼容证明。

让规则缓存绑定环境版本

在规则服务里，可以把“规则文本或规则标识、环境版本、函数库版本”共同作为缓存身份的一部分。这样同一段文本在两套环境中得到的产物不会被误认为完全相同。这里的版本策略是应用层建议，CEL 不会自动为业务环境分配这样的版本号。

迁移时保留旧环境和旧规则产物供仍使用旧契约的请求使用；新的规则版本绑定新的环境和输入契约。待调用方切换后，再按应用自己的生命周期回收旧缓存。不要在一个仅以表达式文本为键的全局缓存里，混用不同环境构造出的 Program。

若应用自定义了 TypeAdapter 或 TypeProvider，也要留意共享可变状态。环境的扩展行为并不替应用保证任意外部对象都成为独立副本；自定义组件应遵守库约定，并由应用确定状态隔离方式。

只有请求值变了，也要重新 Compile 吗？通常应复用适用环境下的 Program，将新值作为输入传入；重新编译主要针对规则或环境契约变化，而不是每次库存值变化。

能直接调用 Check，避免再次 Parse 吗？解析配置未变且 AST 来源合适时可以考虑；涉及宏或解析语义变化时，应从源码重新 Compile。

重新检查通过能消除全部运行错误吗？不能。输入缺失、运行时数据和宿主函数等仍需正确处理，Eval 错误出口应保留。

参考：CEL-Go 环境、检查与编译 API、CEL-Go 官方项目与集成说明。