CPLEX遇到不可行模型时，最怕一上来就盯着某一条约束硬改。更稳的做法是先确认这是不是纯粹的不可行，还是不可行与无界混在一起，再用Conflict Refiner和FeasOpt把问题从整模型缩到少数几条约束和变量界上。IBM官方把预处理诊断、冲突细化和FeasOpt都列为不可行模型的标准排查工具。
一、cplex不可行模型怎么排查
排查不可行模型时，顺序比工具更重要。先判断状态，再缩小范围，最后才去改模型，这样最不容易把真实建模错误和数值问题混在一起。
1、先确认求解状态是不是纯不可行
先看求解结果到底是不可行，还是不可行与无界相关。IBM官方专门把预处理对不可行和无界的早期判定列为第一层诊断入口，说明这一步不能跳过。
2、先用预处理结果缩小排查范围
如果预处理阶段就已经报出明显不可行，优先回查最近新增的约束、变量上下界和大常数设置，不要马上全模型逐条试删。官方文档把这类预处理报告视为进一步分析不可行来源的起点。
3、再调用Conflict Refiner看最小冲突
Conflict Refiner会从不可行模型里提炼出一组互相矛盾的约束和变量界，并尽量收敛到最小冲突。比起直接看整模型，这种结果更适合定位真正的问题核心。
4、把约束按业务分组再回看
拿到冲突集合后，不要只看数学表达式，最好按供需平衡、容量上限、逻辑约束、时间窗口、变量界这几类重新分组。因为IBM官方也提醒，一个最小冲突只是“可导致不可行的一组矛盾”，它未必直接等于最合理的修复方案。
5、需要修复方向时再用FeasOpt
如果你已经知道模型不可行，但还想看“放松哪几条约束代价最小”，再用FeasOpt更合适。IBM官方把FeasOpt定义为按用户给定偏好自动放松模型、尝试修复不可行的工具。
二、cplex冲突约束怎么定位
定位冲突约束的核心，不是把所有约束都列出来，而是把Conflict Refiner给出的冲突结果读成一条清晰的业务链。只要知道谁和谁互相矛盾，后面的修复通常就会快很多。
1、先理解冲突结果里不只有约束，还有变量界
IBM官方明确说明，冲突不只是约束之间矛盾，也可能是约束和变量上下界一起构成矛盾。所以定位时不要只盯约束行，也要同时看相关变量的上下界。
2、优先定位被证明参与冲突的项
如果Conflict Refiner完整跑完，返回的是最小冲突，去掉其中任意一条约束或一个界，子问题就会重新变得可行。这样的结果最适合直接拿来做逐项核查。
3、资源不够时先接受非最小冲突
官方说明里提到，时间限制、节点限制或手动中断时，Conflict Refiner可能只能返回当前最细化到的冲突，而不是严格最小冲突。但这种非最小冲突仍然通常比整模型更有定位价值。
4、一个问题修完后要再跑一次
如果模型里有多个独立的不可行来源，第一次拿到的冲突结果未必是唯一的，修掉一组以后还可能暴露出下一组。IBM官方明确提醒，多重不可行时往往需要迭代处理。
5、冲突细化过程中若忽然变可行，要先查数值问题
IBM官方特别提示，如果Conflict Refiner分析过程中原本不可行的模型突然看起来可行，通常应优先怀疑数值不稳定，而不是继续强行做冲突定位。这时应把注意力转回数值困难和建模尺度上。
三、cplex结果该怎么复核
把不可行和冲突结果跑出来以后，最后一步不是立刻改模型，而是做复核。复核的目的是确认你改动的是根因，不是只把表面矛盾临时压住。
1、先复核最近新增的约束和界
如果冲突集合集中落在最近新增的业务规则、边界条件或上下界上，优先从这些变更点回查，通常比全模型重审更有效。这个做法与IBM把测试和调试重点放在预处理、冲突和修复工具上的思路一致。
2、再复核放松后的业务含义
如果你用FeasOpt找到了最小放松方案，不要马上把它当成最终修复。IBM官方明确指出，FeasOpt是帮助修复不可行的自动工具，但是否合理仍需要你从业务定义上判断。
3、把冲突结果和修复结果一起留档
建议保留三份信息，原始不可行模型、Conflict Refiner输出、FeasOpt或人工修复后的可行模型。这样下次同类问题再出现时，你能更快判断是旧问题复发，还是新约束带来的新矛盾。这个做法最适合长期模型维护。
4、复跑后再确认状态彻底变为可行
最终判断不能只看冲突是否减少，而要看模型是否真正恢复到有界可行状态。IBM官方对不可行诊断工具的整体定位，也是服务于模型测试、调试和最终可行求解。
总结
排查CPLEX不可行模型时，先看预处理和求解状态，再用Conflict Refiner把问题从整模型缩到少数约束和变量界，最后再用FeasOpt辅助判断最小放松方向。定位冲突约束时，要同时看约束和变量界，接受必要的迭代过程，并警惕数值不稳定带来的假象。把状态确认、冲突定位、修复复核这三步固定下来，不可行模型的排查效率会稳定很多。
