3、模块化编译基础：模块依赖图、编译顺序、增量编译与全量编译的概念
在大型企业业务系统中，代码库通常被拆分为数十甚至上百个独立模块。理解模块化编译的核心概念，是定位“编译异常”的第一步。本节将围绕模块依赖图、编译顺序、增量编译与全量编译四个关键概念展开，为后续异常定位打下理论基础。
3.1 模块依赖图
模块依赖图是一个有向无环图（DAG），其中每个节点代表一个模块，每条有向边表示“依赖关系”。例如，模块 A 依赖模块 B，则存在一条从 A 指向 B 的边。依赖图是编译系统决定编译顺序和影响范围的核心依据。
关键特征：
- 无环性：企业级项目严禁出现循环依赖，否则编译将无法确定顺序。
- 传递性：若 A 依赖 B，B 依赖 C，则 A 间接依赖 C。
- 粒度：依赖图可以精确到模块级，也可以细化到文件级（更细粒度用于增量编译）。
3.2 编译顺序
编译顺序由依赖图通过拓扑排序算法确定。拓扑排序保证：对于任意一条边 A → B，节点 B 在排序结果中始终出现在节点 A 之前。这意味着被依赖的模块总是先被编译。
| 排序步骤 | 操作 | 已排序模块 | 剩余模块 |
|---|---|---|---|
| 1 | 选择入度为 0 的模块（无依赖） | D | A, B, C |
| 2 | 移除 D 及其出边，选择新的入度为 0 的模块 | D, B, C | A |
| 3 | 移除 B、C 及其出边，选择入度为 0 的模块 | D, B, C, A | （空） |
实践提示：在 Maven 或 Gradle 等构建工具中，编译顺序是自动计算的。当出现循环依赖时，构建工具会报错并终止编译。这是开发环境中常见的“编译异常”之一。
3.3 增量编译与全量编译
这两个概念决定了编译的效率和触发条件，是开发环境性能优化的关键。
3.3.1 全量编译
全量编译指重新编译所有模块，无论其是否发生变化。通常在以下场景触发：
- 首次构建（clean build）。
- 切换 Git 分支后，依赖关系发生大规模变化。
- 构建脚本或编译器版本升级。
- 持续集成（CI）环境中的稳定发布构建。
3.3.2 增量编译
增量编译只重新编译发生变化的模块及其受影响的依赖模块。它通过以下机制实现：
- 文件哈希比对：比较源文件或编译产物的哈希值，判断是否变化。
- 依赖追踪：记录每个模块的输出文件列表，当依赖模块的输出发生变化时，触发重新编译。
- 缓存机制：将编译产物缓存到本地或远程仓库，避免重复编译。
| 对比维度 | 全量编译 | 增量编译 |
|---|---|---|
| 编译范围 | 所有模块 | 仅变更模块 + 受影响模块 |
| 执行速度 | 慢（分钟级） | 快（秒级） |
| 适用场景 | CI 发布、首次构建 | 本地开发、日常调试 |
| 异常定位难度 | 低（全量重试即可） | 高（需分析增量缓存是否失效） |
异常定位警示：增量编译虽然快，但容易因缓存失效、依赖追踪不完整或文件时间戳错误导致“假成功”或“假失败”。当你在开发环境中遇到“编译通过但运行报错”或“未修改的模块报错”时，应首先尝试执行一次全量编译，以排除增量缓存问题。
3.4 三者关系总结
依赖图、编译顺序、增量/全量编译三者构成了模块化编译的完整逻辑闭环：
- 依赖图是静态结构，定义了模块间的逻辑关系。
- 编译顺序是动态执行计划，由依赖图通过拓扑排序生成。
- 增量/全量编译是执行策略，决定了在给定依赖图和顺序下，实际编译哪些模块。