Django 5.0 数据库连接不自动关闭是因为默认复用连接且仅在请求结束时由 close_old_connections() 清理；非 Web 场景（如管理命令、Celery 任务）需显式调用 connections['default'].close() 才能真正释放底层连接。
为什么 Django 5.0 的数据库连接不自动关闭？
Django 默认复用数据库连接，靠 CONN_MAX_AGE 控制连接池寿命。设为 0 表示每次请求后关闭，但实际仍可能因中间件、信号或异步视图残留连接——尤其在长周期任务（如 Celery、管理命令）中，django.db.connection 可能长期持有一个未关闭的连接，触发 MySQL 的 Too many connections 或 PostgreSQL 的连接数超限。
手动关闭空闲连接的可靠方式
不能依赖 connection.close() 直接调用：它只标记连接为“可关闭”，真正释放需配合 connection.close_if_unusable_or_obsolete() 或等待请求结束。正确做法是：
- 在非 Web 请求上下文（如
manage.py shell、自定义命令、定时任务）末尾，显式调用django.db.connections['default'].close() - 若使用多数据库，遍历
django.db.connections.all()并逐个关闭 - 避免在中间件
process_response中硬关——Django 5.0 已在响应后自动调用close_old_connections()，重复调用可能引发InterfaceError: connection already closed
示例（管理命令中）：
from django.core.management.base import BaseCommand
from django.db import connections
<p>class Command(BaseCommand):
def handle(self, *args, **options):</p><h1>... 执行数据库操作</h1><pre class="brush:php;toolbar:false;"> for conn in connections.all():
conn.close() # 真实关闭底层 socket
CONN_MAX_AGE 设为 0 不等于立即关闭
CONN_MAX_AGE = 0 表示“不复用连接”，但 Django 仍会在请求生命周期内维持一个连接，直到 close_old_connections() 被触发（通常在响应返回后）。它不适用于以下场景：
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
- 同步脚本执行完未退出进程（如后台常驻脚本）
- 使用
threading或concurrent.futures启动新线程访问 DB —— 每个线程有独立连接缓存，主线程关了不等于子线程关了 - 异步视图（
async def）中，await期间连接可能被挂起，CONN_MAX_AGE不生效
此时必须在逻辑出口处主动调用 connections['default'].close()，而非依赖配置。
检查连接是否真已关闭
MySQL 可查 SHOW PROCESSLIST；PostgreSQL 查 SELECT * FROM pg_stat_activity WHERE state = 'idle'。但在代码中验证更直接：
- 调用
connections['default'].connection—— 若为None，说明已关闭 - 捕获
django.db.DatabaseError或底层异常（如psycopg2.OperationalError）来判断连接状态 - 注意：
connection.is_usable()返回False不一定代表已关闭，可能是网络中断或认证失效
最稳妥的验证方式仍是主动关闭后，再尝试一次简单查询并预期抛出异常。
真正的难点不在“怎么关”，而在“什么时候该关”——Web 请求由框架兜底，所有脱离请求周期的代码路径，都得自己负责清理连接。漏掉一个 close()，就可能让连接在后台空转几小时。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
