Go Expr 可选字段为 nil 时怎么避免规则求值失败

Go Expr 规则访问可选指针字段时，最稳妥的写法是先判断字段是否为 nil，再访问它的成员；不要把 profile.Name 直接放进每条规则里赌输入一定完整。Expr 官方示例也使用 name == nil ? ... : ... 处理可选变量，规则编译和运行则分别通过 expr.Compile、expr.Run 完成。

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

如果字段为空代表“没有这个条件”，就让条件表达式先短路返回默认结果；如果字段缺失代表数据契约错误，则应该在 Go 侧补齐或拒绝输入，而不是用宽松选项掩盖问题。

这类失败通常发生在两个位置

先看错误出现的时机。调用 expr.Compile 时报错，说明表达式语法、Env 类型或字段访问关系没有通过编译；编译成功但 expr.Run 返回错误，则更像是运行数据与规则的实际边界不匹配。

用 nil 条件保护可选字段访问

假设业务对象里的 Profile 是可选指针，规则只想在档案存在时检查等级。可以把“没有档案”定义成 false，让后半段只有在前置条件成立时才参与求值：

package main

import (
    "fmt"

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

type Profile struct {
    // Level 是只有在 Profile 存在时才有意义的业务字段。
    Level int
}

type Input struct {
    // Profile 使用指针表达“可能没有档案”的输入状态。
    Profile *Profile
}

func main() {
    // 先判断 Profile，再访问 Level，避免空指针对象进入后续条件。
    code := `Profile != nil && Profile.Level >= 3`

    program, err := expr.Compile(code, expr.Env(Input{}), expr.AsBool())
    if err != nil {
        // 编译错误属于规则契约错误，应在加载规则时尽早暴露。
        panic(err)
    }

    cases := []Input{
        {},
        {Profile: &Profile{Level: 2}},
        {Profile: &Profile{Level: 3}},
    }
    for _, input := range cases {
        result, err := expr.Run(program, input)
        if err != nil {
            // 运行错误需要带着当前输入回到调用方处理。
            fmt.Printf("run error: %v\n", err)
            continue
        }
        fmt.Printf("matched: %v\n", result)
    }
}

这里的关键不是把所有字段都改成默认值，而是先明确业务含义：Profile == nil 时规则应当返回 false。如果“没有档案”意味着需要人工补录，就应当在 Go 侧把它识别为数据问题，而不是悄悄当成不匹配。

编译一次，重复使用同一个 program

Expr 的规则通常来自配置或数据库，加载后可以编译一次，再对多条输入调用 expr.Run。这样既能把规则文本的错误提前暴露，也能让每次求值只处理当前输入。最小的职责划分如下：

// 规则加载阶段：校验表达式并生成可复用的 program。
program, err := expr.Compile(
    `Profile != nil && Profile.Level >= 3`,
    expr.Env(Input{}),
    expr.AsBool(),
)
if err != nil {
    // 规则不可编译时不要把半成品放进缓存。
    return fmt.Errorf("compile rule: %w", err)
}

// 请求处理阶段：每次只替换输入，不重复解析规则文本。
result, err := expr.Run(program, input)
if err != nil {
    // 运行阶段错误要和“规则加载失败”分开记录。
    return fmt.Errorf("evaluate rule: %w", err)
}
matched, ok := result.(bool)
if !ok {
    // AsBool 约束了预期类型，这里仍保留边界保护便于定位配置变化。
    return fmt.Errorf("rule result is %T, want bool", result)
}
return matched, nil

如果规则很多，可以按规则版本缓存 program；缓存键应包含规则内容或版本号。不要只按规则名称缓存，否则更新后的表达式可能继续使用旧的字节码。

未定义变量和 nil 字段不是同一个问题

expr.AllowUndefinedVariables() 允许表达式使用未定义变量，官方示例也展示了先编译规则、后把变量放进环境的方式。但它解决的是“变量是否存在于 Env 定义中”，不等于所有缺失字段都应该被当成空值。

如果输入对象始终有 Profile 字段，只是值可能为 nil，优先使用明确的 *Profile 类型和 nil 条件。只有在规则确实面向部分字段、且业务已经定义缺失字段的默认语义时，才考虑 AllowUndefinedVariables；否则编译阶段的字段错误更容易发现。

另外，Expr 提供 DisableShortCircuit() 用来关闭短路求值。除非你的表达式明确需要所有分支都被计算，否则不要打开这个选项：一旦关闭，Profile != nil && Profile.Level >= 3 就不能再被当成保护空值的可靠边界。规则配置、选项和输入契约必须一起评审。

用三组输入确认规则契约

不要只拿一条完整数据测试。至少准备三组输入：字段为空、字段存在但不满足条件、字段存在且满足条件；如果输入来自弱类型 map，再增加一个字段类型不正确的案例。

如果业务希望“档案缺失”触发另一条规则，可以把它写成显式分支，例如 Profile == nil ? "missing" : "ready"。这样比把空值转换成一个神秘的等级数字更容易维护，也方便后续统计每种输入状态。

常见问题

把字段改成 map[string]any 能解决 nil 吗？

不能。弱类型输入只会把错误推迟到运行阶段。若字段结构稳定，优先用带可选指针字段的 Go 类型，让 Expr 在编译阶段看到明确的 Env。

为什么 Compile 成功，Run 还是会失败？

Compile 只说明规则能按给定 Env 编译，真实输入仍可能出现类型不一致、函数返回错误或关闭短路后的分支问题。两类错误应分开记录。

可选字段为空时一定要用 AllowUndefinedVariables 吗？

不一定。字段存在但值为 nil，使用明确的指针类型和条件保护更合适；只有“变量本来就可能不在环境中”且业务已经约定默认语义时，才考虑该选项。

总结一下：先把可选字段建模成明确的 nil 状态，再用 字段 != nil && 字段成员条件 做保护；规则加载时处理 Compile，请求处理时复用 program 并处理 Run；最后用空值、未命中、命中和类型错误四类输入确认契约。这样既不会把 nil 当成万能默认值，也不会让一条规则的输入边界变成运行时惊喜。