Cargo Build何时重新编译Crate？本地与CI构建差异疑问

你的猜测完全正确——CI每次重新克隆代码时，所有文件的修改时间（mtime）都会被重置为当前时间，而Cargo正是通过对比源文件的mtime和缓存中的记录来判断是否需要重新编译。哪怕src目录内容没变化，新的mtime也会让Cargo认为文件已修改，触发全量编译。

核心原因 #

Cargo的编译增量判断逻辑依赖两个关键信息：

• 文件的修改时间（mtime）
• 文件内容的哈希值
  当文件mtime更新时，Cargo会重新计算内容哈希并与缓存中的旧值对比。CI环境下，git克隆出的所有文件mtime都是当前时间，和缓存中存储的旧mtime不匹配，因此会强制重新编译所有crate。

解决步骤 #

1. 修正CI中文件的修改时间

在actions/checkout之后，添加一步将文件mtime重置为对应提交的时间，让Cargo能正确识别未修改的文件：

- uses: actions/checkout@v3
- name: Fix file timestamps to match git history
  run: |
    git config core.autocrlf false
    git ls-files -z | xargs -0 touch -d "@$(git log -1 --format=%ct)"

这行命令会把所有文件的mtime设置为最后一次git提交的时间，和本地开发环境的文件时间逻辑对齐。

2. 优化cargo-cache的缓存策略

确保缓存key包含足够的唯一性标识，避免缓存命中错误。修改Leafwing-Studios/cargo-cache的配置：

- uses: Leafwing-Studios/cargo-cache@v1
  with:
    # 基于操作系统、Cargo.lock内容生成缓存key，保证依赖不变时缓存命中
    cache-key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
    # 缓存编译后的目标文件
    cache-targets: true
    # 共享依赖缓存（不同项目但依赖相同可复用）
    shared-key: ${{ runner.os }}-cargo-shared

3. 确保提交Cargo.lock到仓库

工作区项目必须提交Cargo.lock文件，这样CI环境和本地环境的依赖版本完全一致，缓存的依赖包和编译产物才能正确复用。

完整CI配置示例 #

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Fix file timestamps to match git history
        run: |
          git config core.autocrlf false
          git ls-files -z | xargs -0 touch -d "@$(git log -1 --format=%ct)"
      - uses: dtolnay/rust-toolchain@stable
      - uses: Leafwing-Studios/cargo-cache@v1
        with:
          cache-key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
          cache-targets: true
          shared-key: ${{ runner.os }}-cargo-shared
      - name: Run tests
        run: cargo test --workspace --release

内容的提问来源于stack exchange，提问作者Fredrik Norén