CI/CD 性能优化与构建缓存：让流水线从 40 分钟缩到 5 分钟

流水线各环节耗时占比（常见）：
  - 依赖安装（pip/npm/go mod download）  30~40% ← 最常见瓶颈
  - 镜像构建（Docker build）              15~25%
  - 编译/打包（compile/tsc/webpack）       15~20%
  - 测试执行                              10~30%
  - 部署                                5~10%

第一步：先跑一次流水线，看哪个 step 最久
  GitHub Actions：Actions 页看每个 job 的耗时
  GitLab CI：Pipeline 图看每 job 时长
  先别急着加缓存——先知道慢在哪

真正拖慢 CI 的，常常不是代码多，而是：
  1. 串行依赖：job B 必须等 job A 做完 → 没有并行
  2. 缓存没配：每次重新下载/重复构建 → 浪费
  3. 排队阻塞：并行数限制，作业排队等待
  4. 冷启动：build 架构/镜像拉取每次都作废

本指南的核心：把"重复计算"变成"命中缓存"，把"串行"改成"并行"

依赖下载通常占 CI 30%+ 的时间：
- 几百个 package/npm/gem/pip 每次全量下
- 网络往返、解压、写入都耗时

解决办法：把依赖缓存下来，只有 lock 文件变化才重下

# GitHub Actions：用 actions/cache 缓存依赖
- uses: actions/cache@v3
  with:
    path: |
      ~/.cache/pip
      ~/.npm
      node_modules
    key: deps-${{ runner.os }}-${{ hashFiles('**/requirements.txt', '**/package-lock.json') }}
    restore-keys: |
      deps-${{ runner.os }}-

# GitLab CI：用 cache 关键字（挂载到缓存卷）
cache:
  key:
    files:
      - requirements.txt
      - package-lock.json
  paths:
    - node_modules/
    - .cache/

Docker 构建按图层号缓存：
  若 BASE 层没变，后面层可复用旧缓存 → 秒级构建
  但默认 Docker 后端不做远端缓存（每次重拉）
  BuildKit 提供：本地缓存 + 远端类型导入（registry / S3）

加成：多阶段构建 + 依赖层在前 → 依赖不变时缓存命中率极高

# GitHub Actions 使用 docker/build-push-action + 缓存
- name: Build and push
  uses: docker/build-push-action@v4
  with:
    context: .
    push: true
    cache-from: type=gha          # 利用 GitHub Actions 缓存
    cache-to: type=gha,mode=max

cache 类型：
  - type=gha     GitHub Actions 专用（简单好用）
  - type=registry (docker.io/org/cache) 场景主常用（推远端 registry）
  - type=local   本地/CI 卷缓存
mode=max：缓存所有中间层（大发减构建时间）

注意：缓存键通常 = 镜像 registry 的 tag/digest；
  多层 cache-from 会让 CI 时快，但首次 push 体积较大

# ✅ 把"变化少的层"放前面，依赖层尽量前移
FROM node:20
WORKDIR /app
COPY package.json package-lock.json ./   # 先复制依赖清单（变化少的）
RUN npm ci --prefer-offline               # 依赖层缓存
COPY . .                                  # 再复制源码（变化多的）

规律：COPY . .（源码）应该尽量靠后。
  源码一变 → 之后所有层都重建；
  依赖 list 几乎不变 → npm ci 层可以长期命中缓存

语言级增量构建：
  - Go:  `-cache`（编译缓存自动）
  - Gradle: 本地/远端 build cache（不变就不重编译）
  - Maven: incremental build / parallel
  - TypeScript: tsc --incremental / esbuild 缓存

GitHub Actions 缓存编译产物：
  把 GOCACHE / ~/.gradle / target 缓存，配上 key
  → 只有相关源码变化才重编译那部分

高阶：测试"选择性执行"
- Gradle: 输入变化时才重跑影响到的测试
- 工具：pytest 的 --cache / 专门的 choose-tests
- 更严谨的选择器：只运行受影响影响的包（依赖图分析）

注意：选择测试有漏测风险——
  建议"增量执行 + 每日全量兜底"，保安全。

1. 精确键（cache-level HASH）：
    命中率高但一换 lock 就全部失效（重建）
      key: cache-${{ hashFiles('lock') }}

2. 恢复键（restore-key 宽松）：
    即使精确键 miss，也能回退到旧的近似缓存
      restore-keys: cache-  (会在其下一个次最接近的用上)

3. 组合键（lang-version-lockhash）：
    版本+lock 一起，既稳定又分版本
      key: cache-linux-node20-${{ hashFiles('package-lock.json') }}

缓存需要主动"失效"场景：
- 依赖升级（lock 变）→ 必然失效
- 平台/CI runner 换（OS/arch 变）→ key 里带上 runner 特征
- 包管理器版本升级 → key 带上
- 避免：把"活的/会变的"当 key 尾（如时间戳）→ 永远 miss

经验：
  - key 尽量稳定（否则命中率低）
  - 用 restore-keys 兜底，减少"完全重下"的次数

# GitHub Actions：不同维度并行跑一个矩阵
strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]      # 跨 OS 并行
    node: [18, 20]                           # 跨版本并行
  # 矩阵展开 = os×node 的组合 → 充分利用并行

# 这对你只是时间和 Runner 成本换并行

作业拆分：
- lint / unit / build / e2e 应并行（同时开始）
- 存在依赖才串行（build → e2e 依赖产物）
- 用 concurrency 防止多余 job 排队（取消旧 run）

进阶：依赖图（DAG）
- .needs 表达依赖，无依赖的并行、有依赖的等
- 把大 job 拆成小 job（build 一份 → 各 job 用产物）
  用 upload/download artifact 传递，避免重复 build

CI 并发不是无限：
- 免费 GitHub Actions 并行有限 → 别开太多 matrix
- 自建 runner 注意 Hub 队列
- 超大 monorepo 用"受影响模块选择" + 并发备份

目标：让整个流水线"最短路径"通过，而不是"每个 job 都快"

并发合并问题：
- 两个 PR 都基于老 main，试跑都绿
- 先后合入 → 合入后的实际状态冲突/挂掉
- Merge Queue（合并队列）解决：把要合入的 PR
  排队，队列里用最新 main + 改动重新跑测试

会带来的好处：
- main 永远"绿进"
- 测试只跑"合并后 real"（不是我 merge 前 fake 绿）
- 减少互相 覆盖 的冲突

# GitHub 需要在仓库启用 merge queue 策略 + 分支保护
# 与并行 CI 结合，让合并队列的被测变更始终是真实最新

结合点：Merge Queue 跑"真实合并"流水线，
  因此缓存 keys 里要反映 merge base——用合并起始 commit 计算，
  避免缓存与真实合并状态冲突

0. 先度量：看哪些 step 最赚钱
1. 依赖缓存：先把 pip/npm/go 缓存配对（最容易的收益）
2. BuildKit 镜像缓存：Docker 副产物（layer cache 命中）
3. 编译/测试缓存：Gradle/GOCACHE/TS --incremental
4. 并行化：拆分无依赖 job，用 matrix+取舍切换
5. CI 时长暴露队列：加 runner / 合并
6. 收敛：每周看 CI 平均时长，做版本回归

把"优化"变成"度量×兑现"的循环，而不是一次冲动

CI 优化要盯的：
- 平均 CI 时长（绿为主）
- 缓存命中率（依赖/镜像/测试）
- 队列/排队时长
- PR 平均到合并时间
- 测试覆盖率/漏测警示

□ 依赖缓存：key 用 lock 文件 hash + restore-keys 兜底
□ BuildKit 远端缓存（gha / registry）提升构建
□ Dockerfile 依赖层前移，最大化图层缓存
□ 编译/测试缓存（GOCACHE/Gradle/incremental）
□ 并行：拆分独立 job + matrix + artifact 复用
□ Merge Queue：真实合并状态下测试
□ 缓存键带 OS/arch/版本，避免失效
□ 用增量测试 但定期全量兜底
□ 持续度量 CI 时长与缓存命中率

CI 提速 = 缓存消化重复 + 并行摊平批次 + 队列守真实合。