govaluate适合90%的动态条件判断场景，但易因字段缺失、空指针、类型不匹配等崩溃；它仅做表达式求值，不支持流程控制、状态持久化或动作编排。
govaluate 适合什么场景，又为什么容易崩
90% 的动态业务逻辑场景，用 govaluate 就够了——但它不是万能的，崩得也快。它只管「条件判断」，不负责流程跳转、状态持久化或动作编排。
常见错误现象：panic: interface conversion: interface {} is nil, not string 或 undefined variable "user.Address.Street"。这不是规则写错了，是传入数据和表达式字段对不上。
-
govaluate要求所有被引用的字段必须存在于map[string]interface{}中（哪怕值为nil），缺一个就 panic - 链式访问如
user.Address.Street会直接崩溃，因为user.Address是nil，它不做空指针防护 - 时间函数（如
today()）默认不支持，必须手动注册函数，且得确保每次调用都实时计算，不能固化初始值 - 表达式里用
==比较字符串时，若一边是nil，会 panic；建议统一用结构体 +json.Marshal/json.Unmarshal做类型兜底
怎么安全地传参和预检变量
别等 Evaluate 时才暴露字段缺失问题。先用 govaluate.GetVariables 把表达式里所有变量名抽出来，再比对实际传入的 map key。
- 高频调用必须缓存
govaluate.EvaluableExpression实例，每次NewEvaluableExpression都会重新 tokenize，性能损耗明显 - 传参前用
maps.Clone（Go 1.21+）或手动补全缺失字段，值设为nil或占位符（如"MISSING"） - 避免在表达式里写
user.City != ""这类隐式非空判断；改用注册的安全访问函数，例如safeGet(user, "City")，自己实现空值 fallback - 如果用 YAML/JSON 加载规则，注意字段命名一致性（大小写、下划线），否则
json.Unmarshal后字段对不上，govaluate照样报未定义变量
Gengine 和 airules 什么时候该选
当你发现 govaluate 开始不够用——比如要按优先级执行多条规则、需要冲突解决策略、或者运营要批量启停某类策略——就得换更重一点的引擎。
-
Gengine支持自定义 DSL、规则分组、优先级排序、事实（Fact）注入和动作（Action）绑定，适合风控、审核、工单路由等需多规则协同的场景；但它要求你写类似 Go 语法的规则文本，还得自己管理规则加载生命周期 -
airules更轻，专注「条件-动作」映射，用 JSON/YAML 定义，集成成本低，适合促销配置、权限开关、设备联动等简单决策流；不支持规则间依赖或循环执行 - 两者都不支持复杂流程编排（如分支嵌套、等待回调、状态机），真要这类能力，得上专门的流程引擎，而不是硬塞规则引擎里
- 如果你的规则要频繁热更新且不能重启服务，
Gengine的动态加载能力比airules更成熟；但若只是静态配置+启动加载，airules的零依赖和低开销更省心
别把规则引擎当万能胶水
规则引擎解决不了「流程怎么走」，只回答「现在该不该做」。真正复杂的业务逻辑，往往卡在上下文传递、事务边界、重试语义和可观测性上。
比如一个优惠券发放规则判定通过了，后续调用发券接口失败，你是重试、降级还是回滚？这些不属于规则引擎职责。它只输出布尔结果或简单动作，剩下的得靠你用装饰器模式包超时/重试/日志，用 GORM 事务封装数据一致性，用结构体明确定义流程节点与实例状态。
最容易被忽略的是：规则变更后的兼容性验证。上线新规则前，务必用旧数据集跑一遍回归测试——尤其是字段类型变更（比如 user.Score 从 int 改成 float64），govaluate 不报错但结果可能偏差。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
