先说一个核心判断：大多数C#项目根本不需要什么独立规则引擎。用switch表达式、Dictionary，或者一个简单的策略类，就能搞定80%以上的业务校验、路由和状态转换场景。过早引入NRules、WorkflowCore这类库，反而让调试更头疼、部署更重——得不偿失。
为什么别急着集成 RuleEngine 或 NRules
真正需要规则引擎的信号其实很明确，只有几个：
- 规则由非开发人员（比如运营）动态配置，而且需要热更新
- 同一个输入要触发几十条相互依赖的条件判断，比如风控评分卡那种场景
- 规则逻辑频繁变更，并且每次改动都需要版本审计和追溯
如果这些都不满足，那switch和Dictionary就是你的朋友，别折腾。
NRules 入门最简路径：从 Session 和 Rule 开始
NRules 是目前C#生态里维护最活跃、DSL最清晰的规则引擎之一。它不支持运行时编辑规则，但编译期定义足够轻量，上手也快。
- 必须继承
Rule类，用[Name]和[Description]标注清楚，方便后面维护 - 条件写在
public override void Define()里，用When()+Match；动作写在() Then()里 - 执行前必须调用
session.Insert(obj)插入事实（fact），否则规则不触发——这是新手最容易忽略的步骤 - 默认不自动循环匹配，需要显式调用
session.Fire()。忘了这句，是入坑最典型的错误
public class AgeEligibilityRule : Rule{ public override void Define() { Person person = null; When() .Match(p => p != null && p.Age >= 18); Then() .Do(ctx => Console.WriteLine($"{person.Name} is eligible")); }}
用 Expression> 实现动态规则更可控
如果规则来自JSON配置或数据库字段，比如"Age > 18 && Status == 'Active'"这种，硬编码NRules就不太现实了。这时候，直接解析表达式比引入完整引擎更稳妥。
- 用
System.Linq.Expressions手动构建表达式树，或者借助System.Linq.Dynamic.Core库 DynamicExpressionParser.ParseLambda能把字符串转成委托，性能损耗可控——首次编译慢一些，后续缓存就好- 注意：用户输入的表达式必须严格白名单校验，禁止访问
GetType()、Assembly等敏感成员，否则有远程代码执行的风险 - 别用
Eval()或CompileToMethod()——它们在 .NET Core/.NET 5+ 的AOT或某些容器环境里可能无法正常工作
Microsoft.Extensions.DependencyInjection 怎么注入规则集合
规则不是单例，而是按业务域分组，比如OrderValidationRules、RefundPolicyRules。最自然的做法就是靠DI容器来管理它们的生命周期。
- 注册时用
services.AddSingleton - 避免用
AddTransient——每次Resolve都新建实例，规则间的状态（比如计数器）无法共享 - 如果规则需要访问数据库或HTTP客户端，构造函数参数必须声明为
IServiceProvider并延迟解析，防止构造时DI循环依赖 - 调用方接收
IEnumerable后，自己控制执行顺序和中断逻辑——比如某个规则返回false就跳过后续
规则引擎真正的复杂点，其实不在语法或API，而在于“规则如何与主业务流程解耦又不失上下文”。比如一个订单创建流程里，风控规则失败了，该抛异常还是降级为日志？是否允许部分规则静默失败？这些决策，比选哪个库重要得多。
