反射取值在规则引擎中性能极差，因每次调用均触发内存分配、类型检查与字符串比对，嵌套访问和map操作开销巨大，GC压力导致高并发下卡死。
Go 语言里用反射做规则变量取值，性能损耗不是“有点慢”，而是直接让规则引擎在高并发下卡死——尤其当单次请求要 eval 数千条规则时，GC 压力和类型断言开销会吃掉 70% 以上的 CPU 时间。
为什么反射取值在规则引擎里特别伤性能
规则引擎的典型执行路径是：解析表达式 → 遍历 AST → 对每个变量节点从 context 中取值 → 比较/计算 → 返回结果。其中“取值”这步如果靠 reflect.Value.FieldByName 或 reflect.Value.MapIndex 实现，问题就来了：
- 每次调用都触发一次完整反射对象构建，
reflect.ValueOf(ctx)本身就要分配内存、检查类型、缓存类型信息 - 嵌套访问如
user.Profile.Address.Street需要 4 层FieldByName，每层都做字符串比对 + 字段查找 + 类型检查 -
map[string]interface{}这类非结构体 context，reflect.Value.MapIndex内部还要做 key 的 hash 计算和桶查找，比原生 map[key] 慢 10–20 倍 - go 1.21+ 的
maps.Clone或 deep copy 也依赖反射，若你在预检阶段反复 clone context，等于主动喂 GC
govaluate 和 expr 默认怎么取值？它们踩了哪些坑
这两个主流库默认都走反射路径，但实现细节不同，导致崩法不一样：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
govaluate对map[string]interface{}做了简单优化：它把变量名切分后用循环查 map，不进反射；但一旦遇到user.Address.Street，它就会尝试user.(map[string]interface{})["Address"].(map[string]interface{})["Street"]—— 这里两次类型断言失败就 panic，且没有 fallback -
expr更激进：它默认只展开一层 struct，user是 struct 指针才支持点号链式访问；传map[string]interface{}时，user.Profile直接报undefined identifier 'Profile'，错误信息完全误导人 - 两者都不缓存字段路径的反射句柄。比如
user.Age在 100 条规则里出现 500 次，每次都要重新reflect.ValueOf(user).FieldByName("Age")，而不是提前拿到reflect.StructField缓存复用
不反射，那变量取值该怎么做
核心思路是：把“运行时反射取值”移到“AST 构建阶段”完成，运行时只剩最轻量的查表或索引操作。
立即学习“go语言免费学习笔记（深入）”；
- 词法分析后，把所有变量路径（如
user.profile.age）解析成[]string{"user","profile","age"}或[]interface{}{"user", "profile", "age"}，存在 AST 节点上 - 提前写一个
getNested(ctx interface{}, path []string) interface{}工具函数，只用原生 map/slice 访问，不碰reflect；对 nil 字段返回nil，由后续比较逻辑统一处理 - 如果 context 是 struct，用
go:generate+golang.org/x/tools/go/packages在构建期生成字段访问器代码，避免运行时反射（类似easyjson的思路） - 高频规则场景下，直接把变量路径编译成闭包：
func(ctx interface{}) interface{} { u := ctx.(*User); return u.Profile.Age }，运行时零开销
真正容易被忽略的点
很多人优化到缓存 EvaluableExpression 就停了，但没意识到：只要变量取值还走反射，哪怕表达式编译再快，整体吞吐也上不去。更隐蔽的是，GC 压力不会立刻报错，而是在 QPS 上到 3000+ 后，P99 延迟突然从 10ms 拉长到 200ms，日志里却只看到 “runtime: scavenger pacing slow”，根本想不到是 reflect.Value 在疯狂 alloc。
