引言：重构交付链路的直觉持续集成与持续交付（CI/CD）长期以来被视为 DevOps 专家的专属领域。但随着 GitHub 在 2019 年通过 GitHub Actions 原生引入 CI/CD 能力，将自动化流水线直接整合进代码仓库已成为开发者触手可及的现实。传统开发中，构建、测试、打包、登录服务器、发布等繁杂操作消耗了大量精力。而 CI/CD 的核心理念在于：通过频繁提交代码自动创建并测试代码，尽早检测错误，将开发者从调试与合并冲突中解放出来。本文旨在通过“外科手术式”的链路重构，将这些日常体力活转化为机器确定性执行的规则，最终建立“git push 即部署完成”的新直觉。第一部分：核心概念与流水线解构在动手重构之前，我们需要理清 GitHub Actions 的核心术语体系，这是构建任何工作流的基础：Workflow（工作流）：持续集成一次运行的过程，存放在代码仓库的.github/workflows目录中，采用 YAML 格式。Job（任务）：一个工作流由一个或多个 Job 构成，可以并行或串行执行。Step（步骤）：每个 Job 由多个 Step 构成，依次执行具体的命令。Action（动作）：可复用的步骤，GitHub 社区提供了超过 11,000 个预构建的 Action 供直接引用。Runner（运行器）：执行任务的服务器，GitHub 免费提供 2 核 CPU、7GB 内存、14GB SSD 配置的云端运行器。一条完整的 CI/CD 流水线职责明确：CI 流水线在代码变更时运行，负责编译代码、执行测试并检查功能完整性；CD 流水线则更进一步，将通过测试的构建产物部署到生产环境。第二部分：从零搭建 CI 工作流1. 创建第一个工作流文件
