本文详解如何使用 optaplanner constraint streams 实现跨实体（shift → employee → tracer → isotope → contract）的日产量约束校验，避免手动实现复杂 constraintcollector，通过嵌套 groupby 与函数式聚合高效完成批次到生产次数的换算与越界惩罚。
在 OptaPlanner 中，针对“每位员工对应一种示踪剂（Tracer），每班次（Shift）消耗 1 批次 Tracer，而每批次 Tracer 需由同位素（Isotope）按固定产出率（batchesPerProduction）生产”这一业务逻辑，核心约束目标是：每个 Isotope 在每日所需的生产次数，不得超过其合同约定的最大日产量（maximumProductionsPerDay）。
关键在于理解数据流转路径：
Shift → Employee → Tracer → Isotope → Contract
其中，Shift 是规划实体，其余均为普通领域对象（非 @PlanningEntity）。OptaPlanner 要求：所有参与约束计算的非实体对象状态变更，必须能被约束流自动感知并触发重计算；否则将导致分数腐败（score corruption）。因此，直接在 ConstraintCollector 中引用 tracer.getBatchesPerProduction() 是安全的——只要 Tracer 及其上游对象（如 Employee 的 tracer 字段）不作为规划变量或事实变更源，该值即为静态配置，无需动态监听。
✅ 推荐实现：零自定义 Collector，纯 Constraint Streams 链式表达
无需编写 BiConstraintCollector 或 TriConstraintCollector，OptaPlanner 内置的 count() 和 sum() 已足够强大。以下是清晰、可维护、符合最佳实践的约束定义：
