健康检查接口应返回200或503状态码：所有关键依赖（DB、缓存、下游API）可用时返回200，任一不可达时返回503并附简短原因；禁止使用4xx，需做轻量级业务探测且避免耗时操作。
健康检查接口该返回什么状态码
HTTP 状态码不是随便选的，200 和 503 的语义差异直接影响上游路由、K8s readiness probe 或负载均衡器行为。服务依赖数据库但连接失败时，返回 200 会让流量继续打进来，等于把故障放大。
- 核心原则：只在所有关键依赖（DB、缓存、下游核心 API）可用时返回
200 - 任一关键依赖不可达，必须返回
503，并附带简短原因（如"db: connection refused"） - 避免用
4xx——健康检查不是客户端错误，是服务自身就绪状态的声明 - K8s 中若 readiness probe 返回非
200，Pod 会从 Service Endpoints 中剔除；用503才能触发这个机制
如何判断“关键依赖”是否真的可用
不能只 ping 主机或端口，得做轻量级业务级探测。比如连上 PostgreSQL 后执行 SELECT 1，而不是只检查 socket.connect() 是否成功。
- DB：用最简查询（如
SELECT 1），超时设为1s以内，避免阻塞整个健康接口 - Redis：用
ping()，别用info()——后者在大数据量实例上可能变慢 - 下游 HTTP 服务：用 HEAD 请求 +
timeout=(0.5, 0.5)，不读响应体 - 本地资源（磁盘、内存）：检查关键路径可写性（
os.access("/var/log/myapp", os.W_OK)），而非总空间
为什么不要在健康检查里做耗时操作
健康检查被 K8s、Nginx、Consul 频繁调用（默认每秒数次），任何同步阻塞都会拖垮整个探针链路，甚至引发级联雪崩。
- 禁止加载配置文件、读大文件、查全表、生成 JWT 密钥等操作
- 禁止调用未加超时的第三方 SDK（如某些老版本 boto3 客户端默认无 timeout）
- 异步任务（Celery worker 活跃度）应单独暴露
/health/worker，不混在主/health里 - 如果必须查状态，缓存结果 10–30 秒，用
threading.Lock或functools.lru_cache控制并发刷新
FastAPI / Flask 中怎么写才不踩坑
框架自带的 BackgroundTasks 或请求上下文生命周期管理，容易让人误以为“只要不 await 就没事”，其实不然。
立即学习“Python免费学习笔记（深入）”；
- FastAPI：别在
@app.get("/health")里直接await db.execute("SELECT 1")——确保 db 是已初始化的 async engine，且 session 已 commit/close - Flask：用
current_app.extensions.get("sqlalchemy")取 DB 实例，别 new 一个新连接；否则连接池快速耗尽 - 共用问题：没设
response.headers["Cache-Control"] = "no-cache, no-store, must-revalidate"，导致 CDN 或浏览器缓存健康响应 - 调试时加个
?debug=1参数，只对内网 IP 开放详细依赖状态，生产环境默认关闭
503，其实不是服务挂了，是它被自己拖死了。 
