github actions自动化部署验证遵循“先测后发”原则，即在部署前自动完成构建、测试、产物可用性、环境配置及部署后冒烟测试等全链路校验，任一环节失败即终止流程。
GitHub Actions 自动化部署验证的核心在于“先测后发”——不是部署完再检查，而是在部署动作执行前，就通过工作流内置的步骤确认代码是否具备可部署条件。验证不等于人工点开页面看一眼，而是由机器自动完成构建、测试、环境兼容性等关键检查。
构建与测试必须全部通过
部署前的验证第一步是确保代码能成功构建并稳定运行。这通常包含：
- 检出最新代码（actions/checkout@v4）
- 安装运行时环境（如 Node.js、Flutter SDK、Python 版本）并启用缓存加速
- 安装依赖（
npm ci、flutter pub get、pip install -r requirements.txt） - 执行静态检查（
flutter analyze、eslint、pylint） - 运行单元测试和集成测试（
npm test、flutter test、pytest），并生成覆盖率报告（可选）
任一环节失败，整个工作流终止，部署不会触发。
产物可用性验证（Build Artifact Validation）
对生成的部署包做轻量级校验，避免“构建成功但包不可用”：
- Android：检查 APK 是否签名、能否解压、
adb install -t -r模拟安装（需 Android runner） - iOS：验证 IPA 包结构、检查 embedded.mobileprovision 是否有效（配合 fastlane）
- Web：用 cypress/run 或 playwright 启动本地服务并访问根路径，确认 HTTP 状态码为 200、标题加载正常
- Serverless/Backend：调用本地健康检查端点（如
curl -f http://localhost:3000/health），要求返回 200
环境与配置预检
防止因环境差异导致上线失败，可在部署前插入验证步骤：
- 检查目标环境变量是否存在且格式合法（例如
ENV=production、API_URL非空） - 用
jq或脚本验证 JSON 配置文件语法（jq empty config.json） - 连接预发布数据库或缓存服务（如 Redis、PostgreSQL），执行简单 ping 或 info 命令
- 若使用 OIDC 身份验证，可添加一步调用云厂商 CLI（如
az account show或gcloud config list）确认凭据已正确注入
部署后快速冒烟测试（Post-Deploy Smoke Test）
部署到 staging 或 production 后，立即发起最小闭环验证：
- 等待应用就绪（如轮询
/healthz直到返回 200，最多重试 60 秒） - 发起一个核心业务请求（如登录接口、首页 HTML 渲染、关键 API 返回字段校验）
- 用 curl + jq 或轻量级 Python 脚本断言响应结构，失败则标记部署异常并通知
- 该步骤建议放在独立 job 中，设置
needs: deploy和if: always()，确保无论部署成功与否都执行
