健康检查接口应返回200 OK状态码和轻量JSON内容，如{"status": "ok", "timestamp": "2024-06-12T10:23:45Z"}，仅做内存态检查，避免阻塞、副作用及敏感信息暴露，并区分/health与/ready语义。
健康检查接口该返回什么状态码和内容
健康检查接口的核心目标是让调用方（比如 Kubernetes、Nginx、Consul）快速判断服务是否“可接受流量”，不是验证业务逻辑是否正确。因此它必须返回 200 OK，不能用 204 No Content 或 4xx/5xx——后者会被负载均衡器或编排系统判定为“不可用”，直接下线实例。
响应体建议用轻量 JSON，字段保持最小必要：
-
{"status": "ok", "timestamp": "2024-06-12T10:23:45Z"}—— 最简形式，无依赖检查 - 若需区分“就绪”和“存活”，可加
ready字段，如{"status": "ok", "ready": true} - 避免返回数据库连接详情、内存占用等敏感或易变信息，这些属于监控范畴，不该出现在健康端点
用 Flask/FastAPI 实现时如何避免阻塞主线程
健康检查本应毫秒级响应，但若在 handler 里同步执行数据库 ping、HTTP 外部调用或文件读写，会拖慢整个服务。常见错误是直接写 db.execute("SELECT 1") 或 requests.get("http://other-service/health")。
正确做法是只做内存态检查，或把耗时依赖设为可选：
立即学习“Python免费学习笔记（深入）”；
- FastAPI 中用
@app.get("/health", include_in_schema=False)，函数体只检查app.state.started这类内存标志 - Flask 中可用
current_app.config.get("HEALTH_CHECK_DB", False)控制是否连 DB；开启时用超时控制，例如db.engine.execute("SELECT 1", timeout=0.3) - 绝对不要在健康接口中触发日志刷盘、缓存预热、配置重载等副作用操作
为什么 /health 和 /ready 通常要分开
Kubernetes 的 livenessProbe 和 readinessProbe 行为不同：前者失败会重启容器，后者失败只是摘除流量。混用同一个接口会导致误判。
典型分法：
-
/health：只检查进程是否存活（例如能否响应 HTTP、主线程未卡死），不依赖外部服务 -
/ready：检查是否准备好接收请求（例如 DB 连接正常、Redis 可写、本地缓存已加载） - 若服务启动慢（如需加载大模型），
/ready初期返回503 Service Unavailable是合理行为，而/health必须始终200
FastAPI 示例片段：
@app.get("/health")
def health():
return {"status": "ok"}
@app.get("/ready")
def ready():
if not app.state.db_connected:
raise HTTPException(status_code=503, detail="DB not ready")
return {"status": "ok", "ready": True}
生产环境必须加的三个防护点
健康接口看似简单，但上线后常因没设限被滥用或误用：
- 限制访问频率：用
slowapi或 Nginx 的limit_req防止探测风暴压垮服务 - 禁用日志记录：Flask 的
logger.disabled = True或 FastAPI 中用background_tasks.add_task(lambda: None)避免每秒几千条健康日志刷爆磁盘 - 关闭 CORS 和认证：健康端点不该走 JWT 校验或需要 Origin 头，否则 K8s 探针会失败；但可通过反向代理限制 IP 段（如只允许
10.0.0.0/8）
最易忽略的是日志关闭——很多团队直到日志轮转失败才发现健康请求占了 90% 的日志量。
