Go CEL 怎样限制表达式求值的成本预算

把 CEL 当作“配置里的几行条件”时，很容易忽略表达式也会遍历列表、调用扩展函数。一次求值如果没有成本预算，规则作者只要把输入集合放大，接口就可能出现延迟抖动。更稳妥的做法是分两层：编译后先用 EstimateCost 做静态准入，真正求值时再用 CostTracking 和 CostLimit 设硬上限。

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

先把解析检查与求值拆开

CEL-Go 的正常边界是“环境定义变量和函数，Compile 生成 AST，再由 Program 复用”。解析和类型检查比单次求值更适合提前完成；把它们放在请求路径里，会把编译成本和表达式执行成本混在一起，也不利于按规则做缓存。

下面这个例子只保留与成本预算有关的骨架。生产代码还应把 Program 按规则版本缓存，并在缓存键中包含环境和扩展函数版本。

package main

import (
    "log"
    "cel.dev/cel-go/cel"
)

func buildProgram() cel.Program {
    // 变量类型越具体，编译期越能发现错误，也越容易估算集合规模。
    env, err := cel.NewEnv(cel.Variable("items", cel.ListType(cel.IntType)))
    if err != nil {
        log.Fatal(err)
    }
    // 先编译，后续请求只复用 Program，不重复解析用户输入。
    ast, issues := env.Compile(`items.map(x, x * x).filter(x, x > 0).size()`)
    if issues.Err() != nil {
        log.Fatal(issues.Err())
    }
    prg, err := env.Program(ast)
    if err != nil {
        log.Fatal(err)
    }
    return prg
}

用 EstimateCost 做静态准入

静态估算不是运行结果，而是根据 AST 和输入规模提示推导成本范围。以列表为例，items 的长度和每个元素的大小会影响 map、filter 等表达式的上界。把估算放在规则发布或缓存前，可以先拒绝明显超出团队预算的表达式。

type costEstimator struct {
    hints map[string]uint64
}

func (e costEstimator) EstimateSize(node checker.AstNode) *checker.SizeEstimate {
    // Path 中的 items.@items 表示集合元素提示，避免把未知输入当成无限大。
    if size, ok := e.hints[strings.Join(node.Path(), ".")]; ok {
        return &checker.SizeEstimate{Min: 0, Max: size}
    }
    return nil
}

func (costEstimator) EstimateCallCost(function, overloadID string, target *checker.AstNode, args []checker.AstNode) *checker.CallEstimate {
    // 未覆盖的扩展调用交给 CEL 默认估算；高成本扩展可在这里补充上界。
    return nil
}

// 规则入库前执行静态估算，超出准入线就不要进入共享缓存。
estimate, err := env.EstimateCost(ast, costEstimator{
    hints: map[string]uint64{"items": 1000, "items.@items": 64},
})
if err != nil {
    return fmt.Errorf("估算 CEL 成本失败: %w", err)
}
if estimate.Max > 100000 {
    return fmt.Errorf("表达式成本上界 %d 超过准入预算", estimate.Max)
}

这里的阈值只是应用侧策略，不是 CEL 的通用安全值。输入规模来自你的业务契约，不能拿一组测试数据的长度代替线上最大规模。

用 CostTracking 和 CostLimit 做运行期保险丝

静态上界仍可能和真实输入有偏差，所以运行期需要第二道限制。创建 Program 时加入 cel.CostTracking 和 cel.CostLimit；求值后，从 details.ActualCost() 记录实际成本。执行函数要把错误原样区分出来，不要把“成本超限”伪装成业务条件不满足。

type runtimeEstimator struct{}

func (runtimeEstimator) CallCost(function, overloadID string, args []ref.Val, result ref.Val) *uint64 {
    // 自定义函数如果访问外部系统，应按真实工作量返回估算值；未知时返回 nil。
    return nil
}

prg, err := env.Program(ast,
    cel.CostTracking(runtimeEstimator{}),
    cel.CostLimit(100000), // 单次求值的硬预算，按服务容量调整。
)
if err != nil {
    return fmt.Errorf("创建 CEL 程序失败: %w", err)
}
out, details, err := prg.Eval(map[string]any{"items": []int64{1, 2, 3}})
if err != nil {
    // 这里记录规则版本、输入规模和错误类别，再交给调用方降级。
    return fmt.Errorf("CEL 求值失败: %w", err)
}
if details != nil && details.ActualCost() != nil {
    metrics.Record("cel.eval.cost", float64(*details.ActualCost()))
}
return out, nil

CostLimit 是单次求值的限制，不是整个 HTTP 请求、租户或进程的总预算。如果同一请求要执行多条规则，还需要在调用方累加实际成本，避免每条规则都在自己的上限内但总量仍然过大。

区分预算超限、业务错误和扩展函数成本

排查时先按来源分三类。解析或类型检查错误说明规则本身不能进入缓存；Eval 返回的运行错误可能来自变量缺失、类型不匹配或成本限制；表达式返回 false 则只是业务条件不成立。三者混在一个“规则失败”指标里，后续很难调预算。

扩展函数尤其要单独看待。CEL 节点成本只能覆盖 CEL 自己知道的工作量；如果扩展函数里查询数据库、访问网络或扫描大型对象，宿主必须在 CallCost 中提供合理估算，并在函数内部使用独立的超时、并发和资源控制。成本预算不是给外部副作用开绿灯。

用分层预算避免一次阈值误伤

最后保留成本分布，而不是只保存一次超限日志：规则版本、输入规模、静态上界、实际成本和错误类别应能关联起来。预算可以先从保守值开始，再根据真实分布逐步调整；如果某个扩展函数始终占据成本大头，优先拆开它的资源边界，而不是盲目抬高 CEL 上限。

相关问题

静态估算能替代运行期限制吗？

不能。静态估算依赖输入规模提示和扩展函数估算，运行时仍可能遇到更大的真实输入；两层应同时存在。

实际成本为空是否代表没有消耗？

不代表。它只说明当前求值没有产生可用的成本详情，监控代码应允许为空，并继续记录求值错误和输入规模。

为什么不能只按表达式字符串长度限流？

字符串长度无法表达集合遍历次数、函数内部工作量和输入数据规模。长度可以做粗过滤，但不能替代 CEL 的成本估算与运行期预算。