在 Debian 上做 Rust 开发时，真正麻烦的通常不是写代码，而是每次提交后还要手动跑构建、测试，甚至重复检查格式和依赖安全。下面按“本地先跑通、再接入 GitHub Actions、最后补上部署和缓存”的顺序整理一遍，方便你判断一套 CI 配置至少该包含哪些步骤，哪些扩展值得加。
先把 Debian 本地 Rust 项目跑通
在接入 CI 之前，先确保项目本地就能稳定执行基础命令。CI 只是把手工流程搬到平台上自动运行，如果本地还没跑通，上线后只会把问题放大。
安装并更新 Rust 工具链
先安装 Rust，并把工具链更新到最新稳定版：
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup update初始化项目或进入现有仓库
如果是新项目，可以直接创建；如果仓库已经存在，就进入对应目录继续配置：
cargo new your_project接下来检查 Cargo.toml 里的依赖是否完整，并确认下面两条命令能够正常执行：
cargo build
cargo test只有这一步稳定，后面的自动化流程才有意义。
为什么这里用 GitHub Actions
如果代码托管在 GitHub 上，GitHub Actions 基本是最省事的选择之一。它不需要额外自建 CI 服务器，仓库里加一个工作流文件就能触发自动构建和测试。
虽然文章场景是 Debian，但工作流里使用的 runs-on: ubuntu-latest 并不冲突。GitHub 提供的 Ubuntu 运行环境与 Debian 使用习惯高度接近，足以覆盖大多数 Rust 项目的 CI 需求。
创建 Rust CI 工作流文件
在项目根目录创建 .github/workflows 目录，然后新建一个 rust.yml 文件。下面这份配置可以作为基础模板直接参考：
name: Rust CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up Rust
uses: actions-rs/setup-rust@v1
with:
rust-version: 1.70.0
- name: Build project
run: cargo build --verbose
- name: Run tests
run: cargo test --verbose
- name: Check formatting (可选)
run: cargo fmt -- --check
- name: Audit dependencies (可选)
run: cargo audit这份配置里最关键的几个点
push和pull_request都监听main分支，意味着主分支提交和合并请求都会触发检查。actions/checkout@v2负责把仓库代码取到运行环境里，没有这一步，后面的cargo命令无从执行。actions-rs/setup-rust@v1会安装指定的 Rust 工具链，这里固定为1.70.0，有助于避免环境漂移。cargo build --verbose和cargo test --verbose是最基础也最必要的两项检查，日志更详细，出错时更容易定位。cargo fmt -- --check和cargo audit属于可选增强项，一个检查格式一致性，一个检查依赖安全状况，适合尽早纳入流程。
需要时再补部署与缓存优化
基础 CI 跑通之后，再考虑扩展功能会更稳妥。最常见的两个方向，一个是自动部署，另一个是缓存 Cargo 依赖与索引。
把构建产物自动部署到服务器
如果你希望主分支更新后自动发布，可以增加一个 deploy 任务，在构建完成后将产物复制到目标服务器：
deploy:
needs: build
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up Rust
uses: actions-rs/setup-rust@v1
with:
rust-version: 1.70.0
- name: Build release version
run: cargo build --release
- name: Deploy to server
run: |
scp target/release/your_project user@your_server:/path/to/deploy
env:
SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}这里有两个前提不能漏：
- 部署任务通过
needs: build依赖前面的构建任务，只有构建成功才继续。 - 要提前在 GitHub 仓库的
Settings → Secrets中添加SSH_PRIVATE_KEY，值为服务器私钥。
如果你的部署方式不是 scp，也可以改成 rsync，逻辑是一样的。
用缓存减少重复下载依赖
Rust 项目在 CI 中经常耗时的地方，不是编译你自己的代码，而是每次重新拉取依赖。可以通过 actions/cache@v3 缓存 Cargo 目录来缩短后续任务时间：
- name: Cache Cargo registry
uses: actions/cache@v3
with:
path: ~/.cargo/registry
key: ${{ runner.os }}-cargo-registry-${{ hashFiles('**/Cargo.lock') }}
- name: Cache Cargo index
uses: actions/cache@v3
with:
path: ~/.cargo/git
key: ${{ runner.os }}-cargo-index-${{ hashFiles('**/Cargo.lock') }}这两段通常插在 Set up Rust 之后。缓存键里使用 ${{ hashFiles('**/Cargo.lock') }}，可以在依赖发生变化时自动更新缓存，避免一直复用旧内容。
提交配置后怎么验证是否生效
工作流文件写好后，把它提交到仓库：
git add .github/workflows/rust.yml
git commit -m "Add Rust CI workflow with GitHub Actions"
git push origin main推送完成后，GitHub 会自动触发工作流。你可以进入仓库的 Actions 标签页查看运行状态和日志。
这里重点看三类信息：
- 构建是否成功，确认编译链路没问题。
- 测试是否通过，确认提交没有破坏现有功能。
- 格式检查和依赖审计是否报错，判断是否需要额外清理代码或升级依赖。
如果平台不是 GitHub，还可以怎么做
如果项目托管在 GitLab，思路并不会变，只是配置文件从 GitHub Actions 的工作流改成根目录下的 .gitlab-ci.yml。例如：
stages:
- build
- test
build:
stage: build
script:
- rustup default stable
- cargo build --verbose
test:
stage: test
script:
- cargo test --verbose再配合 image: rust:latest 使用 Rust 官方 Docker 镜像，就能让 GitLab CI/CD 自动执行构建和测试流程。
一套够用的 Rust CI 至少应该包含什么
对多数 Debian 上的 Rust 项目来说，一套够用的 CI 配置至少应该包含三部分：固定 Rust 版本、自动执行 cargo build 与 cargo test、在提交和合并请求时自动触发。至于 cargo fmt、cargo audit、部署任务和缓存机制，则属于“很值得补上”的第二层能力。
按这个顺序搭建，通常可以先把最核心的质量门槛立起来，再根据项目体量继续补性能和发布链路，而不会一开始就把工作流写得过重、过复杂。
