Go Expr 怎样限制表达式最终必须返回布尔值

把 Expr 当作权限、筛选或路由条件时，调用方真正需要的是一个明确的 bool，而不是“运行后再猜结果类型”。做法很直接：在 expr.Compile 中追加 expr.AsBool()，让类型不符合的规则在编译阶段返回错误；如果规则可能推导成 any，再追加 expr.WarnOnAny()，把这个模糊边界也收紧。

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

最小配置是 expr.Compile(code, expr.Env(Input{}), expr.AsBool())。编译成功后，expr.Run 的结果才适合接收为 bool；规则写成整数、字符串或无法确定的 any 时，应先处理编译错误。

先把返回类型约束放进 Compile

Expr 的类型约束属于编译配置，不是运行完成后才做的补救。下面的规则同时使用输入环境和布尔选项：age >= 18 && enabled 的最终类型是布尔值，因此可以编译成程序对象。

package main

import (
    "fmt"

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

type Input struct {
    Age     int
    Enabled bool
}

func main() {
    code := `age >= 18 && enabled`

    // Env 提供字段类型，AsBool 声明规则必须产出布尔值。
    program, err := expr.Compile(code, expr.Env(Input{}), expr.AsBool())
    if err != nil {
        // 规则不符合接口契约时，在编译边界返回错误。
        fmt.Println("compile rule:", err)
        return
    }

    // 同一个程序可以接收满足 Env 结构的输入对象。
    output, err := expr.Run(program, Input{Age: 20, Enabled: true})
    if err != nil {
        // 运行阶段错误与返回类型检查是两件事，分别处理。
        fmt.Println("run rule:", err)
        return
    }

    // AsBool 已建立契约，此处断言结果为 bool。
    allowed := output.(bool)
    fmt.Println(allowed)
}

这里的关键不是把 output 强行转换成布尔值，而是让 AsBool 先参与类型检查。这样规则写成 age + 1 时，错误会出现在 Compile，不会等到业务分支里才暴露。

区分明确类型与 any 类型

Expr 的类型检查默认会允许某些结果以 any 形式通过。例如从动态数组中取值时，静态分析可能只能得到接口类型，即使当前元素看起来是布尔值。AsBool() 负责声明期望类型，而 WarnOnAny() 负责禁止这种未收窄的 any。

// 明确的比较表达式，返回类型是 bool。
program, err := expr.Compile(`age >= 18`, expr.Env(Input{}), expr.AsBool())

// 动态索引可能得到 any；WarnOnAny 要求规则进一步收窄类型。
strictProgram, err := expr.Compile(
    `let values = [true, false]; values[0]`,
    expr.AsBool(),
    expr.WarnOnAny(),
)
if err != nil {
    // 这里应修改规则表达式，而不是在 Run 后盲目断言。
    fmt.Println("strict compile:", err)
}

_ = program
_ = strictProgram

如果业务只是允许规则返回任意类型，应该使用对应的宽松配置，而不是为了让编译通过删掉错误处理。当前文章的边界是条件规则：调用方需要可靠的布尔结果，所以建议对动态索引、集合元素和自定义函数返回值保持警惕。

把编译错误当作调用方反馈

API 设计上，可以把规则编译封装成一个小接口：输入是规则文本，输出是程序对象或可读错误。这样管理后台保存规则时就能提前提示，而在线请求只负责运行已经通过类型约束的程序。

func CompileCondition(code string) (*vm.Program, error) {
    // 使用稳定的环境类型，避免规则字段在保存后失去约束。
    return expr.Compile(code, expr.Env(Input{}), expr.AsBool(), expr.WarnOnAny())
}

func CheckCondition(code string) error {
    // 编译失败直接交给调用方，不能把错误吞掉再上线规则。
    _, err := CompileCondition(code)
    return err
}

上面的片段需要额外导入 Expr 的 vm 包类型；如果不想让业务层暴露具体程序类型，也可以把返回值包在自己的规则对象中。无论采用哪种封装，错误模型都应保持一致：规则语法错误、字段类型错误和返回类型错误属于编译反馈，运行时输入缺失或自定义函数失败才属于运行反馈。

运行成功后再接收 bool

当 Compile 已经使用 AsBool 成功返回程序对象，运行结果可以接收为布尔值。仍然要保留 expr.Run 的错误处理，因为输入数据、自定义函数或运行环境问题并不会被返回类型选项替代。

如果规则会被缓存，缓存键至少要绑定规则文本和环境契约；规则更新时替换完整的程序对象，不要继续复用旧程序。共享的是编译后的只读程序，传入的业务输入则应由每次调用独立提供。

常见问题

只使用 expr.AsBool() 够不够？

对明确返回布尔值的比较、逻辑组合通常够用；如果表达式可能推导为 any，追加 expr.WarnOnAny() 可以让契约更严格。

AsBool 会把整数自动转换成布尔值吗？

不应把它当作转换器。它用于声明并检查期望的返回类型，整数表达式不满足布尔契约时应在编译阶段返回错误。

为什么还要检查 expr.Run 的 error？

AsBool 约束的是结果类型，不会替代运行阶段的输入访问、自定义函数和其他执行错误处理。

小结：把 AsBool 放在 Compile 的选项中，先确定规则接口，再运行程序；遇到动态值时用 WarnOnAny 进一步收紧，最后才在成功运行后接收 bool。