编译挂住的那一分钟终端里mvn compile跑了三分钟后还在javac阶段没有报错也没有进度。屏幕光标一闪一闪像什么都没发生。这是典型的假死——不是卡住而是编译器在吃一堆有问题的代码边报错边消化只是错误被吞到了某个深处。我当时的判断是先别等直接去看代码证据找出最明显的不一致点修掉再重新跑一次完整编译。第一次定位回归错误的集合项目里有一组回归编译错误最显眼的是类型不匹配。具体表现为某个方法返回值的类型声明和实际使用处不一致。我先把最明显的这处不一致修掉了然后重新执行mvn compile。结果仍然卡在javac阶段。这说明问题不止一处。编译挂住的原因是 javac 在尝试解析多个相互依赖的类时遇到了无法解析的类型引用导致无限等待。真正卡住的根因继续往下挖最终编译日志跑出来后剩下两处明确错误qryStepInfo的值类型声明错误实际应该是Long - String但代码里写成了其他类型泛型方法引用写法不当编译器无法推断类型需要改成显式 lambda这两处错误单独看都不大但组合在一起时javac 在解析依赖关系时进入了某种循环等待状态表现为编译挂住。修复方式很直接把qryStepInfo的类型改对把泛型方法引用换成显式 lambda 表达式。验证与收尾修复完成后重新跑mvn compile编译顺利通过。之后的验证步骤对照前端参数和接口定义确认字段和方法对齐补齐相关业务实现跑后端测试用例整个过程没有用到什么高级调试工具核心思路就一条编译挂住时不要干等先看代码证据定位最明显的错误逐个修复后再验证。可带走的经验遇到mvn compile长时间停在 javac 阶段可以按这个顺序处理不要干等先暂停编译直接看代码找出类型不匹配、方法引用错误等最明显的不一致点修掉明显的错误后重新编译观察是否还挂住如果还挂住继续深挖直到编译日志完整输出拿到完整错误列表后批量修复再跑验证类型错误是编译挂住的常见诱因尤其是泛型方法引用和类型声明不一致的组合。这类问题编译器不会立刻报错而是会消化很久最终表现为假死。做自动化这几年最耗时间的从来不是写代码是摸清每个平台的脾气。这篇里提到的坑都是真金白银踩出来的。如果你手上也有重复度很高的活儿——批量发布、数据搬运、有固定规则的机械操作——可以在评论区说说你的场景我看看能不能自动化掉。