健康检查端点不能用DEBUG=True默认行为，因生产环境需绕过中间件链和认证逻辑，避免404/500/CSRF拦截；必须实现免密、轻量、无副作用的独立路由（如/health/），配合csrf_exempt、极简响应（如"OK"）及Nginx源IP限制，确保K8s探针稳定探测。
健康检查端点为什么不能用 DEBUG=True 时的默认行为？
生产环境健康检查必须绕过 Django 的中间件链和认证逻辑，否则会因 DEBUG=False 下的 404、500 或 CSRF 拦截导致探测失败。Django 默认不提供免密、免中间件的内置健康端点，直接访问 /health/ 这类路径会走完整请求生命周期——包括 AuthenticationMiddleware、SessionMiddleware，甚至可能触发数据库连接检查，这违背“轻量、快速、无副作用”的健康检查原则。
实操建议：
- 不要复用现有视图（如 admin 或 API 接口），避免耦合业务逻辑或权限校验
- 禁用所有中间件对健康端点的影响：要么在 URL 路由前加一层 WSGI 层拦截，要么用
django.views.decorators.csrf.csrf_exempt+ 手动跳过中间件 - 确保响应体极简（如纯文本
"OK"或空响应），避免 JSON 序列化开销和 Content-Type 头协商
如何写一个真正免中间件的 /health/ 视图？
Django 的中间件是全局生效的，但可以通过路由匹配优先级 + 视图装饰器组合实现“逻辑上绕过”。关键不是删除中间件，而是让健康检查在中间件执行前就返回。
实操建议：
- 在
urls.py最顶部添加独立路由：path('health/', views.health_check, name='health')，确保它不被其他通配规则覆盖 - 视图函数必须用
@csrf_exempt，否则 Nginx 或 Kubernetes 的 probe 会被403 Forbidden拦截 - 函数内部禁止调用任何 ORM、缓存、外部服务；只做内存级判断，例如：
return HttpResponse("OK", content_type="text/plain") - 如果需检查数据库连通性，用
django.db.connection.ensure_connection()+except OperationalError捕获，但要设超时（如 1 秒），避免 probe 卡住
为什么推荐用 ALLOWED_HOSTS 配合 Nginx 做前置过滤？
单纯靠 Django 视图免密还不够——攻击者仍可发 GET /health/ 探测服务存活。生产环境要求健康端点仅对内网探测源（如 Kubernetes kube-proxy、ALB、Consul）开放，而非全网可访问。
实操建议：
- 在 Django 的
settings.py中将健康端点 IP 白名单交给反向代理控制，Django 层不做request.META["REMOTE_ADDR"]判断（易被伪造） - Nginx 配置中用
location /health/ { allow 10.0.0.0/8; deny all; }限制来源，再透传给 Django - 务必关闭
USE_X_FORWARDED_HOST和SECURE_PROXY_SSL_HEADER对健康端点的影响，防止 header 注入绕过
manage.py check --deploy 会验证健康检查配置吗？
不会。check --deploy 只校验 DEBUG=False 下的常见安全项（如 SECRET_KEY、ALLOWED_HOSTS、密码哈希器），完全不涉及自定义健康端点是否存在、是否可访问、是否被中间件阻断。
实操建议：
- 上线前手动 curl 测试：
curl -I http://localhost:8000/health/，确认返回 200 +Content-Length: 2（对应 "OK"） - Kubernetes 中使用
livenessProbe时，设置initialDelaySeconds: 10和timeoutSeconds: 2，避免启动竞争 - 若用 Gunicorn，注意其
--preload模式下，健康视图导入早于 settings 加载，os.environ["DJANGO_SETTINGS_MODULE"]必须在进程启动前就设好
最常被忽略的是：Django 的 LOGGING 配置里如果把 INFO 级别日志打到 stdout，高频健康检查会刷爆日志文件，导致磁盘满或日志轮转失效——健康请求应该静默，不记日志。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
