Go Expr AsBool 与普通 Compile 的返回约束有什么区别

我在把 Expr 规则接到布尔判断时，最容易混淆的是“表达式能编译”和“表达式一定返回 bool”。普通 expr.Compile 会保留表达式推导出的结果类型，之后 expr.Run 返回 any；加上 expr.AsBool() 后，编译器会把结果契约固定为布尔类型，算术表达式等非布尔结果会在 Compile 阶段被拒绝。它不是把整数或字符串自动转换成 true/false。

官方地址：https://expr-lang.org/

这一区别适合用在“规则最终就是开关”的场景：让错误尽早暴露，同时仍然把运行时的 error 与业务上的 false 分开处理。

先区分推导结果与期望结果

普通 Compile 只负责解析、检查并生成可运行的程序。例如 score + 1 的结果是数值，enabled && score >= 60 的结果是布尔值。调用方如果只保存一个通用的 program，就要在 Run 后自己判断返回值类型。

AsBool 的作用是给编译器增加一个“这个规则必须产出 bool”的接口要求。Expr 当前实现把期望种类设为 reflect.Bool，检查表达式推导出的 kind；官方示例中，比较表达式可以通过，而 foo + 42 会得到 expected bool, but got int。这属于编译失败，不是运行时把 int 转成 bool。

用同一条规则对比两种 Compile

下面的例子把“是否放行”作为规则结果。普通 Compile 的版本可以编译数值表达式，AsBool 版本则要求最终表达式是比较或逻辑运算。示例只展示调用关系与错误处理，不把输出描述成某台机器的真实运行截图。

package main

import (
    "fmt"
    "log"

    "github.com/expr-lang/expr"
)

func main() {
    env := map[string]any{
        "score":   72,
        "enabled": true,
    }

    // 普通 Compile 保留表达式本身的结果类型，这里得到的是数值结果。
    numberProgram, err := expr.Compile("score + 1", expr.Env(env))
    if err != nil {
        log.Fatalf("普通规则编译失败：%v", err)
    }
    number, err := expr.Run(numberProgram, env)
    if err != nil {
        log.Fatalf("普通规则运行失败：%v", err)
    }
    fmt.Printf("数值结果：%v（%T）\n", number, number)

    // AsBool 要求表达式在编译时就能归类为 bool。
    boolProgram, err := expr.Compile(
        "enabled && score >= 60",
        expr.Env(env),
        expr.AsBool(),
    )
    if err != nil {
        log.Fatalf("布尔规则编译失败：%v", err)
    }
    result, err := expr.Run(boolProgram, env)
    if err != nil {
        log.Fatalf("布尔规则运行失败：%v", err)
    }
    allowed, ok := result.(bool)
    if !ok {
        log.Fatalf("规则结果不是 bool：%T", result)
    }
    fmt.Printf("布尔结果：%t\n", allowed)
}

如果把布尔规则改成 score + 1，AsBool 会在 Compile 阶段失败；如果只是把运行数据里的 score 改成另一个整数，program 仍然可以复用。前者改变了规则类型，后者只改变了输入值。

把编译错误和运行结果分开处理

规则系统中应保留两条错误通道。Compile 的错误说明规则文本、环境声明或返回契约不成立；Run 的错误说明本次求值没有完成。只有 Run 成功并得到 false，才表示条件正常计算后不满足。

Expr 的配置还允许未知类型在某些情况下通过 AsBool 的检查，这是为了兼容动态环境，并不等于运行时结果已经安全。动态 map 中字段类型不稳定时，仍应在消费边界确认 bool，同时记录真实的 Run 错误。

处理动态环境的边界

固定结构体环境更适合布尔规则：Compile 可以看到字段类型，拼错字段名或把数值与字符串混用时更早失败。动态 map 适合字段集合确实变化的场景，但不要把“字段未知”与“结果必然是 bool”混为一谈。

如果业务规则只是一次性返回文本、数字或对象，普通 Compile 更自然；如果规则会进入 if、权限判断或过滤条件，使用 AsBool 能把接口意图写在编译调用处。无论哪种方式，都不要用 fmt.Sprint 或非零判断掩盖类型错误。

AsBool 会把 1 自动变成 true 吗？

不要这样假设。AsBool 约束的是表达式结果的布尔 kind；示例中的整数算术结果会被拒绝。需要转换时，应在 Expr 规则里明确写出可返回 bool 的比较或判断逻辑。

已经用了 AsBool，还要断言 bool 吗？

建议保留。固定环境下它更多是防御式检查；动态环境或后续改动导致契约变宽时，类型断言可以把异常留在边界，而不是让错误值继续传播。

什么时候不该使用 AsBool？

当同一套表达式确实要返回数字、字符串或对象时，不要为了统一接口强行加 AsBool。让普通 Compile 保留真实结果，或者选择与业务返回值匹配的约束方式，代码会更清楚。