c#如何实现规则引擎_c#规则引擎的几种常见用法

先说一个核心判断：大多数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(ruleString) 能把字符串转成委托，性能损耗可控——首次编译慢一些，后续缓存就好
• 注意：用户输入的表达式必须严格白名单校验，禁止访问 GetType()、Assembly 等敏感成员，否则有远程代码执行的风险
• 别用 Eval() 或 CompileToMethod()——它们在 .NET Core/.NET 5+ 的AOT或某些容器环境里可能无法正常工作

Microsoft.Extensions.DependencyInjection 怎么注入规则集合

规则不是单例，而是按业务域分组，比如OrderValidationRules、RefundPolicyRules。最自然的做法就是靠DI容器来管理它们的生命周期。

• 注册时用 services.AddSingleton>(sp => new IRule[] { new OrderAmountRule(), new StockRule() })
• 避免用 AddTransient——每次Resolve都新建实例，规则间的状态（比如计数器）无法共享
• 如果规则需要访问数据库或HTTP客户端，构造函数参数必须声明为 IServiceProvider 并延迟解析，防止构造时DI循环依赖
• 调用方接收 IEnumerable 后，自己控制执行顺序和中断逻辑——比如某个规则返回 false 就跳过后续

规则引擎真正的复杂点，其实不在语法或API，而在于“规则如何与主业务流程解耦又不失上下文”。比如一个订单创建流程里，风控规则失败了，该抛异常还是降级为日志？是否允许部分规则静默失败？这些决策，比选哪个库重要得多。