上下文为什么影响构建速度
构建上下文越大构建越慢：即使只复制少量文件，构建工具也要先把整个上下文打包传给构建器。用忽略清单排除依赖目录、版本库与产物目录是最直接的优化手段，必要时还可以拆分构建目录。
基本信息
| 度量 | 统计当前目录大小并排序找出大目录 |
|---|---|
| 手段 | 用忽略清单排除依赖、版本库与产物目录 |
| 细节 | 较新的构建后端会按需加载，但仍受文件数量影响 |
| 配套做法 | 把依赖安装与源码拷贝分成不同层 |
| 适用范围 | 所有使用构建工具的流水线 |
典型使用场景
- 构建速度明显变慢时先量上下文大小
- 依赖目录与版本库被误打进上下文
- 构建缓存频繁失效导致重复工作
- 流水线里构建耗时波动大的排查
- 制定仓库忽略清单规范
度量与优化
度量与优化
du -sh . ; du -sh * .[!.]* 2>/dev/null | sort -h | tail -8 # 找出最大的目录
docker build --progress plain -t app:1.0 . 2>&1 | head -30 # 观察上下文传输阶段
# 在忽略清单里排除依赖、版本库与产物目录后重新构建对比影响因素与处理
| 关注点 | 影响 | 处理 |
|---|---|---|
| 上下文体积 | 构建前传输耗时 | 忽略无用目录 |
| 文件数量 | 遍历与打包开销 | 拆分构建目录 |
| 层划分 | 缓存命中率 | 依赖与源码分层 |
| 大文件混入 | 每次构建都在传 | 排除转储与压缩包 |
把忽略清单当成与构建文件同等重要的内容维护，能同时改善速度与缓存命中。
整体复制源码后任何改动都会让后续层失效，分层设计里要把依赖安装与源码拷贝分开。
上下文里混入大文件（数据库转储、压缩包）会让每次构建都在传无用数据。
构建日志里能看到上下文传输阶段耗时，用它判断问题出在传输环节还是后续步骤。
多个服务共用一个仓库时，为各自拆分构建目录能显著减小传输量。
同一份忽略清单要覆盖本地开发与流水线两种环境，否则两处行为不一致。