部署完成不等于服务真正运行，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 中写成
deployjob 的 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"
