在 Timefold（或 OptaPlanner）中，若需在同一应用中管理多个独立的规划问题（如不同业务场景的排班、装箱、路径规划），必须为每个解决方案类单独配置 Solver，并确保每个类都标注 @PlanningSolution；直接省略该注解并依赖 XML 或编程式配置会导致初始化失败。
在 timefold（或 optaplanner）中，若需在同一应用中管理多个独立的规划问题（如不同业务场景的排班、装箱、路径规划），必须为每个解决方案类单独配置 solver，并确保每个类都标注 `@planningsolution`；直接省略该注解并依赖 xml 或编程式配置会导致初始化失败。
Timefold（OptaPlanner 的演进分支）严格遵循“一个解决方案类 → 一个求解器配置”的契约。即使你通过 SolverConfig.withSolutionClass() 显式指定类，框架仍会在启动时强制校验该类是否带有 @PlanningSolution 注解——这是元数据提取、实体扫描与约束绑定的前提，不可绕过。
✅ 正确做法：为每个规划问题定义专属的 @PlanningSolution 类，并分别构建独立的 SolverConfig：
// Sol1.java
@PlanningSolution
public class Sol1 {
@PlanningEntityCollectionProperty
private List<Task> taskList;
@PlanningScore
private HardSoftScore score;
// ... getters/setters, problem facts, etc.
}
// Sol2.java
@PlanningSolution
public class Sol2 {
@PlanningEntityCollectionProperty
private List<VehicleRoute> routeList;
@PlanningScore
private BendableScore score;
// ...
}随后在运行时分别创建隔离的求解器配置与管理器：
SolverConfig config1 = new SolverConfig()
.withSolutionClass(Sol1.class)
.withEntityClasses(Task.class)
.withConstraintProviderClass(Sol1ConstraintProvider.class)
.withTerminationSpentLimit(Duration.ofSeconds(30));
SolverConfig config2 = new SolverConfig()
.withSolutionClass(Sol2.class)
.withEntityClasses(VehicleRoute.class)
.withConstraintProviderClass(Sol2ConstraintProvider.class)
.withTerminationSpentLimit(Duration.ofSeconds(60));
SolverManager<Sol1, Long> solverManager1 = SolverManager.create(config1);
SolverManager<Sol2, Long> solverManager2 = SolverManager.create(config2);⚠️ 注意事项：
- 所有
@PlanningSolution类必须满足规范：包含@PlanningScore字段、至少一个@PlanningEntityCollectionProperty或@PlanningEntityProperty，且不可继承自其他@PlanningSolution类； - Spring Boot 或 Quarkus 自动配置目前不支持多
@PlanningSolution场景——它们默认只扫描并注册单个主SolverFactory，因此必须弃用@SolverConfig或optaplanner.solver.config配置项，改用纯编程式配置； - 若需统一调度或多租户能力，建议封装
SolverManager实例为命名 Bean（如@Bean @Qualifier("schedulingSolver")），并在业务层按需注入； - Timefold 社区已意识到该限制，欢迎在 GitHub Issues 提交增强请求（例如支持
@Named("scheduling") @PlanningSolution），以推动未来版本原生集成。
总结：多解决方案不是反模式，而是企业级规划系统的常见需求。关键在于放弃“全局单一配置”的思维，转而采用配置隔离 + 注解合规 + 运行时解耦的设计原则——每个 @PlanningSolution 是一个自治的规划域，各自拥有专属的约束逻辑、终止策略与求解生命周期。
