GitHub Actions 通过 YAML 文件实现免服务器 CI/CD：定义触发事件、运行环境和步骤；建议缓存依赖、矩阵测试、密钥保密；集成覆盖率检查、PR 自动评论、多环境部署及安全扫描。
直接在 GitHub 仓库里配置 YAML 工作流文件，就能启动持续集成。核心是定义“什么时候触发”“在哪运行”“执行哪些步骤”，不需要额外部署服务器。
从一个基础 CI 工作流开始
在项目根目录创建 .github/workflows/ci.yml，内容如下：
- on：指定触发事件，比如推送到 main 分支或打开 PR
- jobs：定义一个 job（例如叫 test），指定运行环境（如 ubuntu-latest）
-
steps：依次检出代码、安装依赖、运行测试——每步用
uses调 Action 或run执行命令
GitHub 会自动识别该文件，下次 push 或 PR 就能看见 Actions 标签页中运行日志。
让构建更稳定和高效
真实项目中建议加入这些关键实践：
- 用
actions/cache@v3缓存 node_modules 或 .m2，避免重复下载，节省 50%+ 构建时间 - 通过
strategy: matrix同时在多个 Node.js 版本或操作系统上跑测试，提前暴露兼容性问题 - 把敏感信息（如 API 密钥、发布令牌）设为 Secrets，在 workflow 中用
${{ secrets.MY_TOKEN }}引用，不暴露在日志或代码里
连接测试与质量门禁
CI 不只是跑通测试，还要守住质量底线：
- 在测试步骤后加覆盖率报告（如 Jest 的
--coverage或 pytest-cov），把结果上传到 Codecov 或 SonarCloud - 用
if: ${{ failure() }}或自定义脚本检查覆盖率是否低于阈值，低于就让 job 失败，阻止低质量代码合入 - 把测试结果自动评论到 PR 页面，让评审者一眼看到变更影响
逐步扩展到完整交付链
CI 稳定后，可自然延伸：
- 在
pull_request触发时只做构建和测试；在push到 main 时追加部署步骤 - 用 Git tag（如
v1.2.0）触发发布流程，自动打包、打镜像、推送到 Docker Hub 或 GitHub Packages - 集成 SAST 工具（如 CodeQL 或 Trivy），在 PR 阶段扫描安全漏洞，问题严重时阻断合并
