咱先抓住关键线索：优化完硬约束得分是0，这说明没有任何硬约束被违反——OptaPlanner的核心规则就是绝对不能碰硬约束，所以岗位没被分配的问题，基本都和硬约束的匹配度有关，下面给你拆解几个最可能的原因，以及怎么排查：

1. 没有员工能满足这个岗位的硬约束要求 #

这是最常见的情况。在呼叫中心这个示例里，硬约束一般包括这些：

• 员工必须具备岗位要求的技能（比如得会英语客服、能处理投诉这类特定技能）
• 员工在这个岗位的时间窗口里，没被安排其他冲突的班次（总不能让一个人同时在两个工位吧）
• 员工当天/当周的工作时长没超上限
• 这个时间段员工没请假、状态是可用的

要是所有员工都卡在上边某一条硬约束上，OptaPlanner宁可不分配，也不会违反硬约束，这时候硬约束得分自然是0（没违规），岗位就留着未分配了。

排查方法：

• 点进那个未分配的岗位，看看它要求啥技能、时间段是啥
• 挨个看看可用员工的技能标签、已排的班次、状态，有没有人能完全对上

2. 求解器停得太早，还没找到可行解 #

如果求解时间设得太短，或者求解器的终止规则被改了（比如“找到第一个可行解就停”），可能求解器还没算出能分配这个岗位的方案就结束了。

不过Demo默认的Solve配置时间应该够，但你可以试试：

• 点完Solve多等会儿，别着急切页面
• 要是能改配置的话，把求解器的termination.spentLimit参数调大，延长求解时间

3. 未分配的状态没同步到求解器里 #

有时候UI上标记了“未分配”，但数据没同步到求解器的输入集里，导致求解器还是按旧的已分配数据在算。

排查方法：

• 标记完未分配刷新下页面，确认岗位确实是未分配状态，再点Solve
• 去OpenShift上对应Pod的日志里看看，求解器启动时加载的数据集里有没有这个未分配的岗位

4. 未分配岗位属于软约束，不是硬约束 #

在Demo的约束规则里，“岗位未分配”可能被设成了软约束——意思是求解器会尽量减少未分配的情况，但实在没辙的话，允许留着。这种情况硬约束得分也是0（没碰硬约束），但软约束得分会因为有未分配岗位而变低。

你可以看看Demo里的约束实现代码（比如EmployeeRosterConstraintProvider类），有没有类似这样的代码：

private Constraint unassignedShift(ConstraintFactory constraintFactory) {
    return constraintFactory.from(Shift.class)
            .filter(shift -> shift.getEmployee() == null)
            .penalize("Unassigned shift", HardSoftScore.ONE_SOFT);
}

这段代码就是把未分配岗位当成软约束来惩罚的。

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