Go CEL 怎样用 PartialVars 保留尚未提供的输入

CEL 的 PartialVars 可以把已有变量与“尚未知道哪些输入”的属性模式一起交给求值器。要让未知值参与部分求值，还需在创建程序时启用 cel.EvalOptions(cel.OptPartialEval)。缺少的值不能简单用 false、0 或 nil 代替；这些值与“暂时不知道”有不同含义。

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

设想一个分阶段判断：本地已知道任务是否启用，另一项 eligible 要稍后由外部服务提供。规则是 enabled && eligible。我们关心的是当前能否得出确定结果，而不是把未到达的数据伪装成拒绝条件。官方旧仓库说明当前规范模块路径为 cel.dev/cel-go，本文示例统一使用它，见 兼容仓库说明。

先比较缺值、零值和未知值

先用“结果属于布尔、未知还是错误”作为对照指标。下面是规则语义推导，不是运行记录或性能压测。缺失输入并不一定使所有表达式都报错；表格使用 enabled=true 的普通求值，确保 eligible 是影响结果的那一项。

这个对照说明部分求值的价值是保留不确定性，并在条件足够时提前得出结论。它不能直接证明省了多少毫秒或减少多少远程调用；这些收益需要具体系统的工作负载数据。

同时配置 PartialVars 与 OptPartialEval

先在环境中声明 enabled、eligible 均为布尔类型，再编译规则。创建程序时开启部分求值；构造输入时用 cel.AttributePattern("eligible") 表明未知的是 eligible。

本节的 已知变量、AttributePattern、PartialVars、PartialActivation、OptPartialEval、Eval 分属输入描述和程序求值：已有变量与属性模式归于 PartialVars，PartialVars 产生 PartialActivation，Eval 使用该输入及相应程序选项。

PartialVars 接口要求手动提供未知属性模式；它不会把 map 中每个缺失键都自动推断为未知。若需要按环境声明推断缺失变量，应另看环境对象的 PartialVars 方法，不能把两个入口混用。

用同一条规则比较三组输入

下面程序复用同一个已编译规则，分别处理“等待 eligible”“已知 enabled=false”和“完整输入”三种情况。项目需在 go.mod 中声明并固定 cel.dev/cel-go 的版本；代码仅供读者使用，本文没有在本地执行。

package main

import (
    "fmt"
    "log"

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

func run() error {
    env, err := cel.NewEnv(
        cel.Variable("enabled", cel.BoolType),
        cel.Variable("eligible", cel.BoolType),
    )
    if err != nil {
        return fmt.Errorf("建立规则环境失败: %w", err)
    }
    ast, issues := env.Compile("enabled && eligible")
    if issues != nil && issues.Err() != nil {
        return fmt.Errorf("编译规则失败: %w", issues.Err())
    }
    // 程序选项与部分输入配套，单独开启选项不会自动补齐变量。
    program, err := env.Program(ast, cel.EvalOptions(cel.OptPartialEval))
    if err != nil {
        return fmt.Errorf("创建求值程序失败: %w", err)
    }

    for _, enabled := range []bool{true, false} {
        // eligible 暂时未知；不要把它写成 false 或 nil。
        input, err := cel.PartialVars(
            map[string]any{"enabled": enabled},
            cel.AttributePattern("eligible"),
        )
        if err != nil {
            return fmt.Errorf("构造部分输入失败: %w", err)
        }
        out, _, err := program.Eval(input)
        if err != nil {
            return fmt.Errorf("部分求值失败: %w", err)
        }
        // 未知必须单独分类，不能强制断言为 bool。
        switch {
        case types.IsUnknown(out):
            log.Printf("enabled=%t：等待更多输入", enabled)
        case out == types.True:
            log.Print("规则确定为真")
        case out == types.False:
            log.Print("规则确定为假")
        default:
            return fmt.Errorf("出现非预期结果类型: %T", out)
        }
    }

    // 数据到齐后传入完整绑定，不再把 eligible 标记为未知。
    out, _, err := program.Eval(map[string]any{
        "enabled": true,
        "eligible": true,
    })
    if err != nil {
        return fmt.Errorf("完整输入求值失败: %w", err)
    }
    log.Printf("完整输入是否确定为真: %t", out == types.True)
    return nil
}

func main() {
    if err := run(); err != nil {
        log.Print(err)
    }
}

按表达式含义，第一次部分求值保持未知；第二次已经可以得到 false；完整输入得到 true。这里的日志文本只是示例中的结果分类，不应把未知结果转换成 out.Value().(bool) 后继续运行。

只把确定的布尔结果交给业务

Unknown 表示当前信息不足，False 表示规则已确定为假，True 表示规则已确定为真；求值错误 则需要独立处理。四者最终交给 业务分类器，其中 Unknown 对应 等待输入，而不是自动允许或自动拒绝。

未知值本身并不是错误，types.IsUnknown 用于识别该类别，相关类型见 CEL 类型接口。上层应为等待、补充输入、超时和错误分别设定策略。

逻辑运算仍可能得出确定结果：false 与未知进行 AND，可以确定为 false；true 与未知进行 OR，可以确定为 true。不要把“存在未知输入”理解为“整个表达式必定未知”。复杂规则还可能包含错误和未知的组合，结果应交由 CEL 的语义处理。

补齐输入后重新求值

PartialVars 不会自动请求外部服务，也不会订阅后续数据，更不是暂停的 goroutine。信息到齐后，由调用方构造新的输入，再使用同一个程序求值。若仍沿用旧的未知模式，可能继续把已经有值的属性当作未知，因此应同步更新绑定和未知范围。

本例只标记整个顶层变量；对象内部某个成员未知时，可用属性限定模式描述更细范围。未知模式越宽，保留的不确定性越多，不要为了省事把整个大对象标成未知，导致本来可以确定的部分无法使用。命名空间场景还需保证模式中的变量名与声明解析后的名称一致。

如需把已知部分化简成剩余表达式，属于残余表达式生成，需要额外的求值状态跟踪和相应 API。仅调用 PartialVars 不会自动返回一段新规则文本。本文保持在“部分输入与结果分类”范围，不把未知结果和残余规则混为一谈。

未提供的布尔值能直接用 false 吗？

只有业务明确将缺失定义为 false 时才适合。若含义是稍后才能获取，应保留未知状态，否则 enabled=true 时会提前产生一个不真实的否定结果。

只配置 OptPartialEval 就够了吗？

不够。它启用相应的求值能力，输入还要通过部分激活对象描述未知属性。普通 map 不会因为开启该选项就自动把所有缺失绑定变成未知。

PartialVars 会保留变量的声明类型吗？

变量声明仍来自编译环境。未知模式告诉运行时哪些属性的值还不知道，并没有免除编译时的名称和类型要求。示例仍完整声明 eligible，即使第一次运行没有提供它的值。