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