OptaPlanner 7.36.0 calculateScore时PlanningVariable未赋值问题

1. 注解关联链路校验 #

• 逐字符核对@ValueRangeProvider标记的id值，和@PlanningVariable中valueRangeProviderRefs数组内的引用字符串是否完全一致，出现大小写、拼写偏差时，框架无法识别可用取值范围，自然不会生成赋值操作。
• 确认承载Team集合的属性/方法，同时标记了@ProblemFactCollectionProperty和@ValueRangeProvider两个注解：仅标记@ProblemFactCollectionProperty不会让框架将该集合识别为规划值的可选池，这是配置中最常见的遗漏点。
• 若homeTeam、awayTeam两个规划变量的可选值范围一致，直接复用同一个range provider即可，无需为两个变量拆分两个完全相同的Team集合。

2. 规划实体识别配置校验 #

• 检查solverConfig.xml中<entityClass>配置的全限定类名，是否和实际编写的Fixture类完全匹配。类名匹配失败时，框架不会将Fixture实例识别为规划实体，自然不会对其规划变量执行赋值逻辑，直接对应观察到的“337次得分计算中261次所有变量未赋值”的现象。
• 若使用注解自动扫描实体的配置，需确认扫描包路径覆盖Fixture类所在目录，避免类加载遗漏。

3. 规划变量的反射访问权限校验 #

• 检查Fixture类中规划变量对应的setter方法：
  • 方法需为public修饰，private/protected权限会导致框架反射调用失败，setter断点自然不会触发。
  • 方法命名需严格符合JavaBean规范，例如homeTeam字段的setter必须为setHomeTeam(Team t)，不能随意修改方法名。
  • 若框架配置为直接字段访问模式，需确认字段非final修饰，且没有被动态代理类包装，否则反射修改会被拦截。

4. 求解器初始化配置校验 #

• 检查solverConfig.xml中<constructionHeuristic>配置段是否正常生效：缺少构造启发式配置时，框架启动后不会为所有规划变量批量生成初始填充值，直接进入局部搜索阶段，就会出现大量变量保持null的计算状态。
• 核对构造启发式的排序配置，避免错误的排序规则导致所有规划变量固定选中Team列表的第一个值，直接对应观察到的“所有Fixture的homeTeam与awayTeam为同一支队伍”的异常结果。
• 当前阶段不需要自定义MoveSelector：框架默认提供的ChangeMove、SwapMove完全可以覆盖两个变量在Team范围内的取值调整，自定义MoveSelector是后期性能优化环节，和当前变量未赋值的问题无关联。

5. 初始Solution状态合理性校验 #

• 传入求解器的初始Solution中，规划变量为null、@PlanningScore为null属于符合框架预期的初始状态，不需要手动提前为变量赋值。
• 无实体对Solution的反向引用，不代表必须重写cloneSolution方法：只要@PlanningSolution类按照规范实现了规划实体集合、规划得分的getter/setter，框架就可以正常完成工作内存的克隆，不会因为缺少反向引用导致赋值失效。

内容的提问来源于stack exchange，提问作者Steve