健康检查

你可能会说：

• “怎么知道我的后端是不是挂了？”
• “部署平台让我填一个 health check 路径，填什么？”

它是什么

服务上线后，要有程序定时确认它还活着：部署平台据此判断新版本是否启动成功、要不要重启，监控据此决定要不要报警。常见做法是提供一个路径（比如 /healthz），正常时返回 200 和一小段状态，异常时返回 503。

好的健康检查会顺手检查最关键的依赖，比如数据库连不连得上，而不只是"进程还在"；同时要足够轻，不能每次都做一大堆事。

最容易踩的坑是量错了对象：请求根本没到后端，被前面某一层接住并返回了 200，监控看到的就永远是"一切正常"。所以检查时不只看状态码，还要看返回内容是不是后端给的。

打个比方

像护士定时量体温：不听病人怎么说，只看体温计上的数字。前提是，体温计得真的夹在病人身上。

在这个网站里

兄弟项目 E2E Review 的后端有一个像样的 /healthz：先查一次数据库，正常返回 200 和一段 JSON，数据库连不上返回 503。可是经过正式域名去请求，拿到的却是一张前端网页：前面的转发脚本只转发 /api/ 开头的地址（第 5 课）。

容易搞混的地方

你可以这样告诉 AI

接下来去哪

先知道

• HTTP 状态码——服务器回应每个请求时附带的三位数字，告诉对方这次是成功、找不到，还是出错了。

对比着看

• 软 404——页面其实不存在，服务器却返回 200，让程序误以为这是一张正常页面。

接着看

• 反向代理——挡在服务器前面的一层：替后面的服务接收请求，再按规则转交给真正处理它的地方。

在这些课里出现

• 第 5 课 · 路由、状态码与兜底

相关的真实事故

• 健康检查地址返回的是一张网页