CI/CD是围绕代码提交自动触发验证、交付、上线的闭环机制，核心是10分钟内确认代码未破坏线上服务；CI是每次push后的自动体检，CD分持续交付（需人工发布按钮）和持续部署（全自动上线）。
CI/CD 不是工具，也不是“配个 .gitlab-ci.yml 就算落地”的流程，而是一套围绕「代码提交」自动触发、验证、交付、上线的闭环机制。它解决的最实际问题只有一个：你改完一行代码，怎么在 10 分钟内确认它没搞崩线上服务？
CI 是什么：每次 git push 后自动跑的“体检”
持续集成（CI）的本质，是把“集成风险”从发布前挪到写完就测。不是等所有人开发完再合并，而是每人每天至少提交几次，每次提交都立刻构建 + 测试 + 扫描。
- 常见错误现象：
本地 npm run build成功，但 CI 报错Cannot find module 'xxx'——根本原因是 CI 环境没装依赖，或package-lock.json没提交 - 必须覆盖的环节：
npm ci（非npm install）、eslint --max-warnings=0、jest --coverage --bail、trivy fs .（基础镜像漏洞扫描） - 关键细节：测试覆盖率阈值要写死在配置里（如
coverageThreshold: { global: { branches: 80 } }），否则 PR 合并后覆盖率掉到 30% 也过得了 CI - 容易踩的坑：用
node:lts镜像跑前端构建，但本地是node:20——版本不一致导致optional chaining语法报错，CI 却不报
CD 分两档：持续交付 ≠ 持续部署
CD 这个缩写最容易混淆。它其实代表两个不同成熟度的阶段，选错会直接引发生产事故。
-
Continuous Delivery（持续交付）：CI 通过后，自动把dist/目录打包成 Docker 镜像，推到Harbor，再部署到staging环境；但上生产必须点一次“发布按钮”——这是绝大多数团队该卡住的位置 -
Continuous Deployment（持续部署）：连“按钮”都不要，只要staging的 API 健康检查 + 日志无 ERROR + A/B 测试转化率波动 - 典型误用：把
master分支直连生产部署，结果一个console.log('debug')提交导致线上日志刷爆磁盘，监控告警延迟 8 分钟才触发 - 正确做法：用 Git 分支策略硬隔离——
dev→test→staging→release/v1.2（打 tag），生产只认 tag，不认分支
流水线不是越长越好：4 个阶段够用，多一个就多一个故障点
企业常堆砌“标准化流水线”：代码扫描 → 构建 → 单元测试 → 集成测试 → 安全扫描 → 性能压测 → UAT → 部署 → 回滚验证……结果平均耗时 23 分钟，开发者开始绕过 CI 直接改生产库。
- 推荐精简结构：
lint→build→unit+e2e→deploy-staging - 性能敏感点：集成测试别放 CI 阶段，改用 nightly job；UAT 必须人工介入，放 CD 阶段但不自动触发
- 环境一致性陷阱：CI 用
docker build，CD 用helm upgrade，但 Helm Chart 里的image.tag写死成latest——导致 staging 和 prod 实际跑的镜像 hash 不一样 - 回滚必须可验证：CD 流程末尾加一步
kubectl rollout undo deployment/myapp --to-revision=123并检查rollout status，不能只写“支持回滚”四个字
真正的难点不在配置 YAML，而在定义清楚：谁对 staging 环境稳定性负责？谁有权 approve 生产发布？当 trivy 扫出 CVE-2025-12345（中危）时，是阻断流水线，还是降级为警告？这些决策比任何工具链都重要。
