如何在 Java 中通过 if 的多条件组合逻辑实现复杂的营销活动资格判定流程

Ja va营销活动资格判定，核心挑战从来不是“能不能写”，而是“改不改得起”。把一堆杂乱的 if 嵌套或者超长的 && 逻辑堆在一起，初期看似爽快，一旦规则变动、场景叠加，后续维护就是一场噩梦。真正靠谱的做法，是把业务规则结构化、可读化、可维护化。下面聊几个贴近实际生产环境的组织方式。

用策略+条件组合代替硬编码 if 嵌套

把每个资格条件拆成独立的 判定单元，比如“是否新用户”“近30天是否有订单”“当前余额是否≥100”。每个单元只干一件事：返回 true 或 false。然后通过组合逻辑把它们拼起来：

• 定义接口：interface EligibilityRule { boolean test(User user, ActivityContext ctx); }
• 实现具体规则类：IsNewUserRule、HasRecentOrderRule、BalanceAboveRule 等
• 用工具类组合：比如 AllOfRule.of(ruleA, ruleB, ruleC) 表示“全满足”，AnyOfRule.of(ruleX, ruleY) 表示“任一满足”

这么做的直接好处是：每个规则独立可测，改一个不会影响另一个，组合逻辑一目了然。

用责任链动态组装判定流程

活动规则往往是动态的——618要加验身份证实名，双11要跳过风控拦截。这种场景下，责任链模式就派上用场了。每个处理器只负责一个判断节点，前一个返回 false 或抛异常，后续直接跳过（比如“未登录→直接拒”）。

• 每个处理器实现 boolean handle(User user, ActivityContext context)
• 链的执行顺序可以按活动 ID 从 DB 或 JSON 加载配置，实现真正的动态编排
• 规则变了，改配置即可，不用改代码，更不用重新上线

这种方式的精髓在于：把“顺序”和“逻辑”分离，让系统活得久。

避免布尔爆炸：把 if 条件转成表达式引擎（轻量级）

运营同学经常拍脑袋改规则：“会员等级≥3 且 近7天GMV＞500 或 有指定优惠券”。如果每次都要开发改代码，效率太低。这时可以引入轻量级的表达式引擎，比如 A viatorScript 或 JEXL，让规则以字符串形式配置：

• 写一条规则字符串："(user.vipLevel >= 3) && (stats.gmv7d > 500 || user.hasCoupon('COUPON_2024'))"
• 预编译 + 缓存，性能足够应对日常营销场景
• 配合白名单函数和沙箱机制，禁止 System、Runtime 等危险调用，保障安全

这样一来，运营自己就能在后台配置规则，开发彻底解放。

补充：日志与可观测性不能少

资格判定失败时，光 return false 远远不够。必须知道“卡在哪一步”，否则排查问题像大海捞针。几个实用建议：

• 每个规则执行后记一条 trace 日志，带上 ruleId、输入值、结果、耗时
• 用 MDC 打上 activityId/userId，方便按用户或活动快速定位
• 对高频拒绝场景（比如“风控拦截”“余额不足”）设置监控告警，辅助运营复盘

这些看似细节，但正是线上稳定性的最后一道防线。