部署完成不等于服务真正运行，CI/CD末尾必须自动校验线上服务状态：检查主入口、核心资源、健康端点，设响应时间阈值（如≤300ms），连续请求取平均，失败则中断发布并告警。

部署完成不等于服务就真的跑起来了。CI/CD 流水线的最后一步，必须包含对线上服务真实运行状态的自动校验，否则就只是“假成功”。关键不是等人工去点开网页或 curl 一下，而是让系统自己确认——它是否可访问、响应是否合规、核心功能是否就绪。

健康检查项需聚焦业务关键路径

不要检查所有接口，只盯住真正代表服务“活了”的几个点：

• 主入口页面：比如 index.html 能返回 HTTP 200，且 HTML 内容不为空（防止 Nginx 默认页误判）
• 核心资源文件：如 Yuedu 项目中的 shuyuan 文件，不仅要求状态码正确，还需用 jq 验证 JSON 格式合法
• 轻量级健康端点：后端服务应暴露 /health 或 /actuator/health，返回结构化 JSON 并含 "status": "UP"

响应质量要设阈值，不止看通不通

连得上不代表体验好。需结合历史数据设定响应时间红线：

• 国内 CDN 节点建议 ≤300ms 为正常，300–500ms 发警告，>500ms 或超时即判定失败
• 脚本中用 curl -w "%{time_total}" 获取耗时，再乘以 1000 换算成毫秒，与阈值比对
• 避免单次波动误判，可连续请求 3 次取平均，或要求至少 2 次达标才通过

集成到流水线末尾，失败即中断发布

把校验脚本作为部署阶段的最后一个 job，确保它在目标环境生效后立即执行：

• GitLab CI 中写成 deploy job 的 downstream，用 needs: ["deploy"] 显式依赖
• Jenkins Pipeline 里放在 stage('Deploy') { ... } 后面紧接 stage('Verify') { ... }
• 校验失败时必须 exit 1，触发流水线中断，并通知负责人（如发 Slack 或邮件）

补充验证：不只是 HTTP 层

对有后台进程或定时任务的服务，还需跨层确认：

• 检查 systemd 服务状态：systemctl is-active --quiet myapp && systemctl is-failed --quiet myapp
• 验证进程是否存在：pgrep -f "myapp.jar" > /dev/null
• 若依赖数据库，可执行简单查询：mysql -h db -u user -p'pass' -e "SELECT 1"