为何Gurobipy已找到最优解却输出错误的最终求解结果？

我是Gurobipy新手，在使用其求解任务调度问题时，设计了一个简单案例，已知最优值为33.7(s)。Gurobi在早期迭代中似乎已找到最优解，输出如下：

Explored 1 nodes (124 simplex iterations) in 0.01 seconds (0.01 work units)
Thread count was 8 (of 8 available processors)

Solution count 1: 33.7 

Optimal solution found (tolerance 1.00e-04)
Best objective 3.370000000000e+01, best bound 3.370000000000e+01, gap 0.0000%

但之后却输出了错误的最终解：

Explored 1 nodes (100 simplex iterations) in 0.01 seconds (0.01 work units)
Thread count was 8 (of 8 available processors)

Solution count 1: 0 

Optimal solution found (tolerance 1.00e-04)
Best objective 0.000000000000e+00, best bound 0.000000000000e+00, gap 0.0000%
IIS runtime: 0.01 seconds (0.01 work units)

0显然不是正确值，为何会出现这种情况？为何Gurobi找到最优解后却转向错误解？按预期Gurobipy找到最优解后应停止求解，却输出错误结果。

从两次求解的输出差异来看，核心原因是两次求解的模型状态不一致——第一次求解的是你设计的原始任务调度模型，第二次求解的是被修改后的模型，才会出现先对后错的结果。以下是最可能的几个原因及排查方向：

• 模型被意外修改：第一次solve()调用后，你的代码大概率执行了修改模型的操作，比如删除目标函数、将变量的上下限重置为0、移除了关键约束，甚至重新定义了目标函数。第二次求解时，Gurobi处理的是被篡改后的模型，自然得到0这个错误结果。
  排查：检查第一次求解完成后到第二次求解前的代码段，重点看是否有调用model.setObjective()、var.setAttr('UB', 0)、model.remove(constr)这类会修改模型结构的方法。

• IIS计算导致模型变更：第二次输出里出现了IIS runtime，说明你可能调用了model.computeIIS()方法。计算IIS（不可行性的最小集合）时，Gurobi会自动松弛约束、调整模型状态来定位不可行原因，这个操作会直接改变原始模型的结构。如果在计算IIS后没有重新加载原始模型就再次求解，得到的必然是错误结果。
  排查：查看代码中是否有computeIIS()的调用逻辑，确认是否在该操作后使用了原始模型副本，而非被修改后的模型。

• 重复求解时未重置模型状态：如果你的代码多次调用solve()，但没有在每次求解前确保模型回到初始状态，也会出问题。比如第一次求解后，某些求解器参数（如ModelSense）被意外修改，或者变量的取值被重置后未恢复。
  排查：每次求解前，建议创建原始模型的副本（model.copy()），用副本进行求解操作，避免修改原始模型；或者在求解前重新初始化模型的目标函数、约束和变量边界。

• 目标函数被错误重置：如果代码中不小心将目标函数的所有系数设为0，或者直接把目标函数定义为常数0，求解器自然会输出0作为最优值。
  排查：检查setObjective()的调用逻辑，确认目标函数的表达式没有被错误覆盖。

快速定位技巧：在第一次求解后，立即导出模型为LP文件（model.write("original_model.lp")），第二次求解前也导出为modified_model.lp，对比两个文件的差异，就能直观看到模型被修改的地方。

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