Go Expr 表达式读取不存在的字段时怎么提前发现

要在 Go Expr 执行前发现不存在的字段，先把固定结构体环境传给 expr.Compile 的 expr.Env 选项，并保留默认的未知变量限制。规则里的拼写与字段定义不一致时，编译错误就能阻止该规则被启用。不过，嵌套 map[string]any 的动态键不能等同于结构体字段：缺失键可能得到 nil，不能指望编译器根据一份样本数据锁定它的全部键。

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

先让编译器看见环境契约

最小写法是 expr.Compile(rule, expr.Env(Env{}))。Env 定义了表达式能访问的名称和类型。不要仅在 Run 时提供数据，随后期待前面的 Compile 已经知道数据结构。需要提前拒绝规则时，必须处理 Compile 的 error，错误不为空就不能继续使用其 program。

例如容量规则使用 Device.Capacity：顶层环境声明 Device，Device 的类型声明 Capacity。编译器因此知道字段存在。若规则写成 Device.Capcity，缺少的不是运行数据，而是字段定义；向实际对象填入更多数据并不能修复拼写。

分清顶层变量和嵌套字段

顶层 map 环境的键可以声明变量，但其中一个变量若仍然是动态 map，它内部的键集合不是结构体的固定字段清单。官方文档专门对照了动态 map 缺失键与结构体未知字段的不同表现。提前发现固定路径拼写，关键不是“任何 map 都不能用”，而是路径上的对象是否保留了具体类型。Expr 环境与字段访问文档

若固定的设备字段来自外部数据，可以先转换为 DeviceSpec，再交给规则。转换成功和字段必填是两件事：Capacity 为零可能是合法输入，也可能缺少业务数据，应由调用方按业务规则处理。本文不把结构体零值当作“字段存在且输入一定完整”的保证。

用正反两条规则定位缺失字段

在已有 Go 模块中添加 Expr 依赖，把代码保存为 main.go。示例不模拟生产事故，也不伪造具体错误行号：读者运行时应看到正常规则可求值，拼错字段的规则在编译阶段被拒绝。

# 在当前Go模块添加依赖，保留go.mod和go.sum中的解析版本
go get github.com/expr-lang/expr
# 运行下面的正反规则示例
go run .

package main

import (
    "fmt"
    "log"
    "github.com/expr-lang/expr"
)

// 具体结构体保留固定字段信息，避免用动态map代替契约。
type DeviceSpec struct {
    Capacity int
}
type Env struct {
    Device DeviceSpec
}

func main() {
    env := Env{Device: DeviceSpec{Capacity: 12}}
    rules := []string{
        "Device.Capacity >= 8",
        "Device.Capcity >= 8", // 故意漏字，用于观察编译拒绝。
    }
    for _, rule := range rules {
        // 每条规则先按同一环境类型编译；失败后不进入运行。
        program, err := expr.Compile(rule, expr.Env(Env{}), expr.AsBool())
        if err != nil {
            fmt.Printf("规则被拒绝：%s；原因：%v\n", rule, err)
            continue
        }
        result, err := expr.Run(program, env)
        if err != nil {
            log.Fatalf("规则运行失败：%v", err)
        }
        allowed, ok := result.(bool)
        if !ok {
            log.Fatalf("预期bool，实际为%T", result)
        }
        fmt.Printf("规则可用：%s；结果：%t\n", rule, allowed)
    }
}

在真实规则保存接口里，把 Compile 错误返回给规则编辑者，而不是像演示程序一样只打印。只有 Compile 成功，才更新当前启用的 program。若新规则不通过，保留旧的可用版本；不要保存一个错误规则后等待请求流量碰到它。

不要用放宽选项掩盖拼写问题

AllowUndefinedVariables 是允许未定义变量的配置，并不是“提前发现字段”的增强开关。固定规则场景不要为了让错误名称通过而打开它。项目实现将该选项关联到 Strict 配置；AsBool 则约束表达式返回布尔值，不能替代字段契约。Expr 编译选项实现

排查时依次核对四件事：Compile 是否收到 Env；路径上的对象是不是具体结构体；字段名是否受 expr 标签重命名；是否启用了放宽未定义变量的配置。修复后给规则集保留一条有效规则和一条故意拼错的规则作为应用测试用例。这里描述的是读者项目的接入方法，不声称已经在本机执行测试。

字段有 expr 标签时用哪个名字？

用标签定义的表达式名。规则作者看到的接口名可能与 Go 字段名不同，应把这个接口名作为规则编辑提示，而不是临时猜大小写。

Compile 成功能证明所有输入都有效吗？

不能。它能检查已声明的类型与名称，但当前数据是否满足业务要求、动态键是否齐全、运行是否正常仍需分别处理。Run 的 error 不能被业务 false 替代。

为什么从 JSON 得到的 map 不容易提前报字段错？

动态键集合缺少固定字段定义。若字段集合确实固定，可先转成专用结构体；若字段本来就是扩展属性，则保留 map，并明确规定必需键与缺失值的处理方式，不把动态对象当作静态契约。