用curl -w做部署后巡检需将状态码视为业务健康信号：1.按接口语义定义预期状态码范围；2.用-w一次性捕获状态码、跳转链和耗时；3.脚本实现批量巡检与分级响应；4.集成到部署流程中自动验证服务就绪。
直接用 curl -w 做部署后自动巡检，核心不是“查到200就完事”，而是把状态码当作业务健康信号来读——比如302跳转是否意外、403是否暴露权限漏洞、503是否真因资源过载。下面这四步，能让你在10分钟内搭出一个真正管用的巡检机制。
定义关键接口与预期状态码范围
别默认只认200。不同接口语义不同：
-
健康检查接口（如
/health）：合法状态码应为200或204，出现503需立即告警 -
重定向接口（如
/login）：允许301、302，但若返回302却没带Location头，说明配置异常 -
静态资源接口（如
/static/logo.png）：200正常，404表示构建产物缺失，需触发CI重推
用-w一次性捕获状态码+跳转链+耗时
单条命令就能看清全貌，避免多次请求干扰判断：
输出示例：STATUS:200 REDIRECT: REDIRECT: TIME:0.142；若返回 STATUS:302 REDIRECT:https://auth.example.com/login TIME:0.217，说明跳转正常且可控。
写轻量脚本做批量巡检与分级响应
以下逻辑可直接放入部署流水线末尾（如GitLab CI的 after_script）：
- 对每个待检URL执行
curl -w命令，提取http_code和time_total - 状态码不在白名单 → 记录日志并退出非零码，阻断上线流程
- 响应时间超阈值（如 >1s）→ 输出警告但不中断，供后续优化参考
- 检测到
000（连接失败）或5xx→ 触发企业微信/钉钉机器人通知值班人
集成到部署流程中，而非单独运行
巡检必须成为发布动作的自然延伸：
- 在K8s滚动更新后，用
curl -w检查 readiness probe 对应路径，确认新Pod真正就绪再切流量 - 在Ansible部署Nginx配置后，检查
/status接口是否返回200，避免配置语法错误导致服务不可用 - 将脚本封装为Docker镜像，在CI环境统一运行，规避本地curl版本差异导致误判
