Gurobi模型一报不可行，很多人第一反应就是去删约束，结果越改越乱。更稳的做法，其实是先分清状态，再做定位。Gurobi官方说明得很明确，若状态是INFEASIBLE，说明模型已被证明不可行；若状态是INF_OR_UNBD，就还不能直接当作不可行处理，需要先把DualReductions设为0，reset模型并重新optimize，一般才会得到更明确的INFEASIBLE或UNBOUNDED结论。也就是说，排查的第一步不是找“哪条约束错了”，而是先确认你面对的真的是不可行，而不是不可行和无界混在一起。

　　一、Gurobi模型不可行怎么排查

　　模型不可行时，最怕一上来就全局盲改。Gurobi官方给出的主线其实很清楚，先确认状态，再用IIS做诊断，必要时再用feasRelax看最小松弛方向。这个顺序的好处是，你先知道“哪一组条件互相打架”，再决定“怎么修”，不会把原模型的业务含义越拆越散。

　　1、先看求解状态

　　如果日志里已经是Infeasible model，或者状态码是INFEASIBLE，才能继续做不可行定位。若还是INF_OR_UNBD，就先按官方建议把DualReductions设为0，再reset后重求一次。很多人第一步就跳过这层，后面算IIS时其实连问题类型都还没分清。

　　2、再算IIS

　　Gurobi官方把IIS定义得很明确，它是一组仍然不可行、且去掉其中任意一个成员就会变可行的最小冲突子系统。调用computeIIS之后，Gurobi会把结果写回一组属性，包括IISConstr、IISLB、IISUB、IISSOS、IISQConstr和IISGenConstr。这样你就不必对着全模型硬看，而是先收缩到真正互相冲突的那一小块。

　　3、IIS算出来后先导出再读

　　官方说明，computeIIS之后可以把模型写成.ilp文件，这个文件只包含IIS对应的部分。实务里这一步很有用，因为你可以把冲突子系统单独拿出来读，通常比在完整模型里来回翻约束名更快。

　　4、必要时再做feasRelax

　　如果你的目标不只是“知道哪里冲突”，还想看“松到什么程度才会可行”，那就继续用feasRelax或feasRelaxS。官方说明里写得很直接，这类例程会构造一个可行性松弛模型，目标是最小化对原约束和变量界的违背量。它不是替代IIS，而是帮助你看修复方向。

　　二、Gurobi冲突约束怎么定位

　　真正定位冲突约束时，不要把IIS理解成“唯一答案”。Gurobi官方明确提醒，一个不可行模型可能有多个IIS，求解器返回的那个不一定是最小规模的那个，也不一定是你最关心的那组业务约束。所以定位时要把IIS当成第一批嫌疑对象，而不是最终裁决。

　　1、先看IISConstr和变量界属性

　　如果某条线性约束的IISConstr为1，说明它落进了当前IIS；若变量上下界的IISLB或IISUB为1，说明冲突不一定只在约束本身，也可能是变量界限把模型卡死了。很多人只盯Constr，却忽略了界限冲突，这会漏掉一类很常见的问题。

　　2、MIP模型先接受“定位会更贵”

　　官方说明computeIIS可以用于连续模型和MIP，但MIP版本可能会很昂贵。因此大模型排查时，别把IIS当成秒出结果的工具。若模型特别大，可以先收缩到可疑子模型，再求IIS，通常更现实。

　　3、必要时用Force属性缩小范围

　　如果你已经知道某些约束一定要保留，或者某些约束只是辅助约束，官方还提供了IISConstrForce、IISLBForce、IISUBForce等属性，可以强制某些元素进入或退出IIS计算。这一步很适合第二轮排查，用来把冲突范围进一步压到你真正关心的业务规则上。

　　4、看IISMinimal判断结果够不够“干净”

　　若IIS计算中被TimeLimit、WorkLimit、MemLimit或SoftMemLimit打断，Gurobi会返回截至当时找到的最小不可行子系统，但它未必已经是严格最小。官方给了IISMinimal属性来检查这一点，所以IIS拿到以后，最好顺手确认它是否已经最小化。

　　三、不可行排查时先改什么更稳

　　真正容易把排查做乱的，不是工具不会用，而是顺序反了。先改业务约束，后看数值问题，往往会把本来是建模尺度或容差边界导致的问题，当成逻辑冲突去修。Gurobi的数值指南明确建议，在接近不可行边界的模型上，可以先把FeasibilityTol收紧到1e-9，再重新求解、算IIS或做feasRelax，这样更容易分清是真冲突还是数值边界效应。

　　1、先查界和等式

　　多数冲突都更容易先出现在变量上下界、容量约束、平衡等式和互斥条件上。IIS一出来，优先看这些地方，通常比先翻目标函数附近的业务约束更快。这个建议是依据Gurobi返回IISConstr、IISLB、IISUB这几类属性的设计逻辑做出的。

　　2、再查容差和数值尺度

　　如果模型本来就在可行与不可行边缘，先收紧FeasibilityTol再看结果，会比直接删约束更稳。因为官方已经明确把这一步列为边界不可行问题的首选诊断动作。

　　3、最后再决定修模型还是放松模型

　　若IIS明确指出是业务规则互相矛盾，就该回建模逻辑本身修；若业务规则都必须保留，那就更适合用feasRelax去量化“最小改动代价”。这两条路不是一回事，前者是找错，后者是妥协。

　　总结

　　Gurobi模型不可行怎么排查，Gurobi冲突约束怎么定位，关键不是一报错就删约束，而是先把状态分清，再把冲突范围收小。先确认是INFEASIBLE还是INF_OR_UNBD，再用computeIIS缩到冲突子系统，结合IISConstr、IISLB、IISUB去看究竟是约束冲突还是变量界冲突；若还要看修复方向，再用feasRelax。顺着这条线做，排查会比一开始就大改模型稳得多。