Go CEL 动态类型输入为什么仍可能出现运行时类型错误

在 Go 里把 CEL 变量声明为 cel.DynType，并不等于“运行时什么类型都能直接参与任意运算”。dyn 主要告诉检查器暂时不要要求一个固定的静态类型；真正从 map、JSON 或 protobuf 动态值取出字段后，CEL 仍要在求值阶段决定字段的实际类型，并寻找可用的操作符重载。类型不匹配时，错误就会从编译阶段延迟到运行时。

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

要解决这类问题，先把“动态输入”与“动态转换”分开：输入可以声明为 dyn，但进入比较、算术或成员调用前，仍要用类型守卫、短路条件或 Go 边界归一化确认它的形状。

dyn 放宽的是检查，不是运行时契约

CEL 的 dyn 是类型检查阶段的提示，不是一个会在运行时替你转换值的容器。比如表达式引用 payload["age"] 时，如果 payload 的类型是动态的，检查器无法在编译期确定 age 一定是 int，因此会把一部分判断留到实际求值时。

这正是动态 JSON 输入有用的地方：同一个已编译程序可以接收字段集合不同的对象。但它也带来清晰的边界：字段可能不存在，字段可能是字符串而不是整数，集合可能混入不同元素，成员调用还可能找不到匹配的重载。动态类型把“现在无法判断”推迟了，并没有把这些情况变成合法操作。

为什么同一条表达式会在 Eval 阶段报错

假设业务把外部 JSON 解码到 map[string]any，表达式希望判断年龄：

package main

import (
    "fmt"
    "log"

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

func main() {
    // dyn 允许表达式先通过类型检查，但不承诺 age 一定是整数。
    env, err := cel.NewEnv(
        cel.Variable("payload", cel.DynType),
    )
    if err != nil {
        log.Fatal(err)
    }

    // 这里的比较会依赖运行时取出的 age 类型和可用重载。
    prg, issues := env.Compile(`payload["age"] > 18`)
    if issues != nil && issues.Err() != nil {
        log.Fatal(issues.Err())
    }

    // 外部数据把 age 写成字符串时，运行时没有可直接使用的比较组合。
    out, _, err := prg.Eval(map[string]any{
        "payload": map[string]any{"age": "18"},
    })
    if err != nil {
        log.Printf("CEL 求值失败: %v", err)
        return
    }

    // 输出只表示本次求值结果；生产代码还应按业务记录表达式和输入摘要。
    fmt.Println(out)
}

这里要分开看两次错误：Compile 负责语法、声明和可静态判断的类型问题；Eval 负责把本次 activation 中的真实值带入表达式。若 age 是整数，比较可以找到对应关系；若它是字符串，表达式就可能产生类型错误或没有匹配重载。错误发生在后一步，并不说明 DynType 失效。

类似问题还会出现在 payload.user.name 的成员选择、size(payload.items) 的参数类型、混合元素列表的函数调用，以及自定义函数的参数重载上。排查时应同时记录变量声明、表达式文本、实际输入的类型摘要和 Eval 错误，不要只看编译是否成功。

先守卫类型，再进入强类型操作

动态字段适合用于“字段可能变化”的入口层，但不适合毫无保护地接入比较和算术。CEL 支持用 type() 查看值的 CEL 类型，再利用 && 的短路语义，让右侧操作只在左侧确认后参与求值：

package main

import (
    "log"

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

func buildAgeProgram() cel.Program {
    // 动态输入保留入口的弹性，具体字段在表达式内先做类型守卫。
    env, err := cel.NewEnv(cel.Variable("payload", cel.DynType))
    if err != nil {
        log.Fatal(err)
    }

    // 左侧先确认类型，&& 短路后才允许右侧执行数值比较。
    prg, issues := env.Compile(`type(payload["age"]) == int && payload["age"] > 18`)
    if issues != nil && issues.Err() != nil {
        log.Fatal(issues.Err())
    }
    return prg
}

func main() {
    prg := buildAgeProgram()

    // 字符串输入会让守卫为 false，避免把字符串交给整数比较。
    out, _, err := prg.Eval(map[string]any{
        "payload": map[string]any{"age": "18"},
    })
    if err != nil {
        log.Printf("CEL 求值失败: %v", err)
        return
    }
    log.Printf("判断结果: %v", out)
}

这种写法的结果是“类型不符合时返回 false”，而不是把字符串猜测性地转成整数。若业务确实允许字符串数字，应在 Go 边界完成明确的解析、范围检查和失败策略，再把统一的整数值送入 CEL；不要把隐式转换责任交给每条表达式。

混合集合和自定义函数也会把错误推迟

动态问题不只来自 map 字段。一个包含整数和字符串的列表可能被视为带有动态元素的集合，某些函数调用会因此在检查阶段保留下来，直到真实元素参与重载匹配才暴露错误。若业务要求列表同质，可以在环境侧启用更严格的聚合字面量检查，或者在进入 CEL 前把 Go 数据整理成明确的 []int64、[]string 等形状。

自定义函数同样要把 overload 定义当作契约：明确参数类型和返回类型，函数绑定内部不要默认把任意 ref.Val 当成某一种 Go 值。动态输入适合在边界处接收，函数内部则应尽早检查并返回可诊断的 CEL 错误。

上线前把动态入口收窄到可观测边界

动态 CEL 适合做规则入口，不适合让每条业务表达式自行猜测数据格式。比较稳妥的做法是：Go 接收 JSON 或 map 后先做字段存在性、类型和范围归一化；CEL 环境只对确实需要动态性的字段使用 DynType；表达式在强类型操作前用 type() 和短路条件守卫；求值错误带上表达式标识与脱敏后的类型摘要。

如果字段结构已经稳定，优先把变量声明成 cel.MapType(cel.StringType, cel.IntType)、具体对象类型或明确的列表类型。静态声明越精确，错误越早出现，运行时路径越简单。只有在结构确实由外部配置决定时，才保留动态输入，并把“字段缺失”“类型不符”“操作不支持”分别映射成可处理的业务结果。

常见问题

cel.DynType 会自动把字符串转成整数吗？

不会。它主要影响类型检查阶段的约束，真实值仍按 CEL 的类型参与运行时操作。需要转换时，应使用 CEL 明确的转换表达式或在 Go 边界完成解析，并处理失败情况。

为什么 Compile 成功还不能说明表达式安全？

因为动态变量的部分字段类型只能在 activation 到来后确定。Compile 通过只代表当前可静态判断的部分成立，Eval 仍可能因为字段缺失、实际类型或 overload 不匹配返回错误。

所有动态输入都应该改成固定类型吗？

不必。配置字段、JSON 规则和跨版本数据经常需要动态入口；关键是把动态范围限制在边界，进入比较、算术、成员调用和自定义函数前再收窄，并保留可观测的错误信息。

总结来说，Go CEL 的动态输入解决的是“编译期暂时无法知道类型”的问题，不会消除运行时类型契约。理解 DynType、activation 实际值和 overload 匹配的分界，再配合 Go 侧归一化与 CEL 内的类型守卫，就能把一类难定位的运行时错误提前收窄到可解释、可记录的边界。