尧图网站建设 
1. 长连接跑着跑着就报 InterfaceError 的真实场景Django MySQL 的服务跑在容器或常驻进程里白天请求量正常到了凌晨或者某个空闲时段之后突然开始刷pymysql.err.InterfaceError: (0, )。这个报错最迷惑的地方在于代码没改、数据库没重启、账号密码也没动但就是某个时间点之后疯狂出错重启进程又能好一阵。先把结论说清楚pymysql.err.InterfaceError: (0, )在 Django MySQL 场景下绝大多数情况不是 SQL 写错了而是连接池里那条 TCP 连接已经被 MySQL 服务端或中间网络设备单方面断掉了但 Django 这边的连接对象还以为自己活着。等你下次拿它去cursor.execute()pymysql 往一个已经关闭的 socket 上写数据直接抛 InterfaceError。这个报错适合谁看用 Django 跑常驻服务gunicorn/uwsgi/celery/定时任务的开发者尤其是数据库连接配置了CONN_MAX_AGE或者用了连接池、服务空闲一段时间后必炸的同学。下面我会把复现步骤、close_old_connections的调用时机、可复制的配置骨架、验证动作和排障清单全部走一遍你可以直接对着改。先看典型堆栈的关键几层理解它为什么发生在_execute_commandpymysql/connections.py, line 793, in _execute_command raise err.InterfaceError(0, ) pymysql.err.InterfaceError: (0, )_execute_command是真正往 socket 写 MySQL 协议包的地方。它抛 InterfaceError 且错误码是 0说明底层 socket 已经不可写而不是 MySQL 返回了业务错误。所以修复方向不是改 SQL而是在合适的时机丢弃失效连接、重建连接。2. 为什么连接会失效MySQL wait_timeout 与 Django 连接生命周期要修得明白得先知道连接是怎么死的。MySQL 服务端有个wait_timeout默认常见 28800 秒也就是 8 小时和interactive_timeout。一条连接空闲超过这个时间服务端会主动把它关掉。除此之外云数据库的代理层、负载均衡、NAT 网关通常有更短的 idle 超时有的 300 秒、600 秒就断这解释了为什么某个时间点突然开始——往往是服务空闲了一段时间或者流量低谷期连接被中间设备回收了。而 Django 这边如果CONN_MAX_AGE设成了非 0比如 600Django 会复用这条连接不会每个请求都新建。问题就出在这Django 复用的是自己进程里缓存的连接对象它并不知道服务端已经把连接关了。于是下一次请求拿到这条僵尸连接一执行就炸。close_old_connections()干的事很朴素遍历当前线程里 Django 持有的所有数据库连接如果连接已经不可用或者超过了CONN_MAX_AGE就把它关掉下次用的时候重新建。它不会无脑关掉所有连接而是判断这条连接是不是该退休了。所以修复的核心逻辑是在每次可能用到数据库之前先让 Django 检查并清理掉过期/失效的连接。Django 的请求-响应周期里其实已经自动调用了它在请求开始和结束但你的场景如果是 Celery 任务、后台线程、长轮询、定时脚本这些不走标准请求周期就得手动调。3. TaoToken 前置把模型接入和数据库排障串起来写这类排障文章时我习惯把验证模型输出和验证数据库连接分开做避免两个变量互相干扰。如果你在调 Django 服务的同时还要接大模型能力比如让模型帮你分析日志、生成排障建议可以先把模型侧的 Key 和接入方式准备好这样排障脚本里能顺手调用。TaoToken 的入口在这里注册后到控制台拿 Key官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content控制台拿 Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteAPI 基地址统一用https://taotoken.net/api这个不加 UTM。如果你只是想快速验证模型通不通用模型对话页面最省事模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite长期跑编码类任务、Agent 类任务的话Coding Plan 更合适Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewriteClaude Code 相关接入看这个ClaudeCodeAnthropichttps://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecode-anthropicutm_campaignrewrite注意模型接入和数据库连接是两条独立的链路。排障时先保证数据库这条链路稳定再去验证模型输出否则日志里两类错误混在一起很难定位。4. 可复制配置settings 骨架 close_old_connections 调用时机4.1 数据库配置骨架先给一份可以直接抄的 Djangosettings.py数据库配置。关键参数是CONN_MAX_AGE和CONN_HEALTH_CHECKS# settings.py DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: your_db, USER: your_user, PASSWORD: your_password, HOST: 127.0.0.1, PORT: 3306, CONN_MAX_AGE: 60, # 连接最长复用 60 秒别设太大 CONN_HEALTH_CHECKS: True, # Django 3.1 复用前做健康检查 OPTIONS: { charset: utf8mb4, connect_timeout: 5, read_timeout: 30, write_timeout: 30, }, } }几个参数的含义对照参数作用建议值CONN_MAX_AGE连接复用秒数0 表示每请求关闭30~60别超过中间设备 idle 超时CONN_HEALTH_CHECKS复用前 ping 一下连接是否可用TrueDjango 3.1connect_timeout建连超时5read_timeout读超时30write_timeout写超时30CONN_HEALTH_CHECKS True是很多人忽略的关键项。开了它之后Django 在复用连接前会做一次轻量检查发现连接死了就重建能挡掉相当一部分 InterfaceError。但注意它只在标准请求周期里生效Celery、线程、脚本里还是得手动调close_old_connections。4.2 close_old_connections 的正确调用时机先看最小可复现的修复写法也就是你贴的那段import django.db django.db.close_old_connections() print(list(django.contrib.auth.models.User.objects.all()))但每次用 model 前都手动调不是长久之计容易漏。正确做法是分场景场景一Celery 任务。用信号在任务前后自动清理# your_app/celery_signals.py from celery.signals import task_prerun, task_postrun from django.db import close_old_connections task_prerun.connect def _close_before_task(**kwargs): close_old_connections() task_postrun.connect def _close_after_task(**kwargs): close_old_connections()场景二自定义后台线程 / 长轮询。在线程循环里每轮开始前调一次import time from django.db import close_old_connections def worker_loop(): while True: close_old_connections() # 每轮先清理失效连接 try: do_something_with_orm() except Exception as e: logger.exception(worker error: %s, e) time.sleep(5)场景三管理命令 / 定时脚本。在入口处调一次即可# management/commands/run_sync.py from django.core.management.base import BaseCommand from django.db import close_old_connections class Command(BaseCommand): def handle(self, *args, **options): close_old_connections() # 你的业务逻辑场景四中间件兜底。如果你不确定哪些路径会漏加个中间件在请求进入时清理# your_app/middleware.py from django.db import close_old_connections class CloseOldConnectionsMiddleware: def __init__(self, get_response): self.get_response get_response def __call__(self, request): close_old_connections() response self.get_response(request) close_old_connections() return response然后在settings.py的MIDDLEWARE里加上your_app.middleware.CloseOldConnectionsMiddleware。提示Django 标准请求周期本身已经会在请求开始/结束调用close_old_connections所以普通视图一般不用额外加。真正需要手动调的是不走请求周期的那些执行体Celery、线程、脚本、WebSocket consumer。4.3 顺手把模型接入配置也放进来如果你排障脚本里要调模型分析日志可以放一份settings.json风格的配置骨架非 Django settings是给脚本/工具用的{ taotoken: { base_url: https://taotoken.net/api, api_key: sk-你的key, model: claude-sonnet-4-5, timeout: 60 }, database: { conn_max_age: 60, conn_health_checks: true, close_old_connections_before_use: true } }调用侧示例import json import requests cfg json.load(open(settings.json))[taotoken] resp requests.post( f{cfg[base_url]}/v1/messages, headers{ x-api-key: cfg[api_key], anthropic-version: 2023-06-01, content-type: application/json, }, json{ model: cfg[model], max_tokens: 512, messages: [{role: user, content: 帮我分析这段 Django 报错}], }, timeoutcfg[timeout], ) print(resp.status_code, resp.text[:200])5. 复现步骤与验证确认修复真的生效光改代码不算数得能复现、能验证。下面这套流程我实测下来比较稳。5.1 复现 InterfaceError第一步把 MySQL 的wait_timeout临时调小加速复现SET GLOBAL wait_timeout 30; SET GLOBAL interactive_timeout 30; SHOW VARIABLES LIKE %timeout%;第二步写一个脚本先查一次库然后 sleep 超过 30 秒再查一次import time import django import os os.environ.setdefault(DJANGO_SETTINGS_MODULE, your_project.settings) django.setup() from django.contrib.auth.models import User print(first query:, list(User.objects.all()[:1])) time.sleep(40) # 超过 wait_timeout print(second query:, list(User.objects.all()[:1])) # 这里大概率炸第三步运行它你会看到第二次查询抛pymysql.err.InterfaceError: (0, )。这就复现成功了。5.2 验证修复在第二次查询前加上close_old_connections()import time import django import os os.environ.setdefault(DJANGO_SETTINGS_MODULE, your_project.settings) django.setup() from django.db import close_old_connections from django.contrib.auth.models import User print(first query:, list(User.objects.all()[:1])) time.sleep(40) close_old_connections() # 关键清理失效连接 print(second query:, list(User.objects.all()[:1])) # 应该正常返回预期结果第二次查询正常返回数据不再抛 InterfaceError。如果还是炸往下看排障章节。5.3 用连接状态辅助验证想更直观地看连接有没有被重建可以在查询前后打印连接 idfrom django.db import connection, close_old_connections print(conn id before:, id(connection.connection)) close_old_connections() print(conn id after:, id(connection.connection))如果close_old_connections真的关掉了旧连接connection.connection会变成None下次查询时重建id 会变。这能帮你确认清理逻辑确实执行了。6. 本篇常见错排查清单改完还报错的话按下面顺序排查基本能覆盖 90% 的情况。排查一CONN_MAX_AGE 设太大。如果你设了 3600 甚至更大而中间设备 300 秒就断那连接必然失效。把CONN_MAX_AGE降到比中间设备 idle 超时更小的值比如 60。这是最常见的坑。排查二CONN_HEALTH_CHECKS 没开。Django 3.1 以下没有这个参数3.1 建议开。开了之后标准请求周期能自动挡掉失效连接。检查你的 Django 版本python -c import django; print(django.get_version())排查三Celery 没接信号。Celery worker 是常驻进程不走请求周期必须用task_prerun/task_postrun信号调close_old_connections。很多人只改了视图忘了 Celery结果任务里照样炸。排查四多线程共享连接。Django 的数据库连接是线程绑定的close_old_connections只清理当前线程的连接。如果你自己开了线程池每个线程都要各自调。别在线程间传 connection 对象。排查五连接被中间件/代理断掉。云数据库代理、K8s Service、NAT 网关都可能有更短的 idle 超时。这种情况除了调小CONN_MAX_AGE还可以在 MySQL 侧开tcp_keepalive或者用连接池中间件如 ProxySQL管理连接。排查六错误码不是 0 的 InterfaceError。如果错误码不是(0, )而是别的比如(2006, MySQL server has gone away)那可能是包太大或查询超时方向不同。(0, )基本就是连接已断。排查七改了没生效。确认你改的是运行环境实际加载的 settings容器里可能有多个 settings 文件或者环境变量覆盖了配置。打印一下实际生效的值from django.conf import settings print(settings.DATABASES[default].get(CONN_MAX_AGE)) print(settings.DATABASES[default].get(CONN_HEALTH_CHECKS))排查八close_old_connections 调了但没关。它只在连接过期或不可用时才关。如果你刚建完连接立刻调它不会关。想强制关可以显式connection.close()但一般不需要。最后补一个我踩过的坑close_old_connections不是万能的它解决的是连接失效后没被清理的问题。如果你的服务本身连接泄漏比如手动开了 cursor 没关、事务没提交那得从代码层面修。排障时先看 MySQL 的SHOW PROCESSLIST确认连接数是不是异常增长再决定是清理策略问题还是泄漏问题。数据库连接这块稳定之后如果你还要接模型做日志分析或自动化排障回到前面 TaoToken 的接入文档和 API Keys 页面把 Key 配好用https://taotoken.net/api作为基地址就能跑通。两条链路各自验证、互不干扰排障效率会高很多。 Django 运行中 pymysql.err.InterfaceError 超时报错：用 close_old_connections 修复数据库连接
1. 长连接跑着跑着就报 InterfaceError 的真实场景Django MySQL 的服务跑在容器或常驻进程里白天请求量正常到了凌晨或者某个空闲时段之后突然开始刷pymysql.err.InterfaceError: (0, )。这个报错最迷惑的地方在于代码没改、数据库没重启、账号密码也没动但就是某个时间点之后疯狂出错重启进程又能好一阵。先把结论说清楚pymysql.err.InterfaceError: (0, )在 Django MySQL 场景下绝大多数情况不是 SQL 写错了而是连接池里那条 TCP 连接已经被 MySQL 服务端或中间网络设备单方面断掉了但 Django 这边的连接对象还以为自己活着。等你下次拿它去cursor.execute()pymysql 往一个已经关闭的 socket 上写数据直接抛 InterfaceError。这个报错适合谁看用 Django 跑常驻服务gunicorn/uwsgi/celery/定时任务的开发者尤其是数据库连接配置了CONN_MAX_AGE或者用了连接池、服务空闲一段时间后必炸的同学。下面我会把复现步骤、close_old_connections的调用时机、可复制的配置骨架、验证动作和排障清单全部走一遍你可以直接对着改。先看典型堆栈的关键几层理解它为什么发生在_execute_commandpymysql/connections.py, line 793, in _execute_command raise err.InterfaceError(0, ) pymysql.err.InterfaceError: (0, )_execute_command是真正往 socket 写 MySQL 协议包的地方。它抛 InterfaceError 且错误码是 0说明底层 socket 已经不可写而不是 MySQL 返回了业务错误。所以修复方向不是改 SQL而是在合适的时机丢弃失效连接、重建连接。2. 为什么连接会失效MySQL wait_timeout 与 Django 连接生命周期要修得明白得先知道连接是怎么死的。MySQL 服务端有个wait_timeout默认常见 28800 秒也就是 8 小时和interactive_timeout。一条连接空闲超过这个时间服务端会主动把它关掉。除此之外云数据库的代理层、负载均衡、NAT 网关通常有更短的 idle 超时有的 300 秒、600 秒就断这解释了为什么某个时间点突然开始——往往是服务空闲了一段时间或者流量低谷期连接被中间设备回收了。而 Django 这边如果CONN_MAX_AGE设成了非 0比如 600Django 会复用这条连接不会每个请求都新建。问题就出在这Django 复用的是自己进程里缓存的连接对象它并不知道服务端已经把连接关了。于是下一次请求拿到这条僵尸连接一执行就炸。close_old_connections()干的事很朴素遍历当前线程里 Django 持有的所有数据库连接如果连接已经不可用或者超过了CONN_MAX_AGE就把它关掉下次用的时候重新建。它不会无脑关掉所有连接而是判断这条连接是不是该退休了。所以修复的核心逻辑是在每次可能用到数据库之前先让 Django 检查并清理掉过期/失效的连接。Django 的请求-响应周期里其实已经自动调用了它在请求开始和结束但你的场景如果是 Celery 任务、后台线程、长轮询、定时脚本这些不走标准请求周期就得手动调。3. TaoToken 前置把模型接入和数据库排障串起来写这类排障文章时我习惯把验证模型输出和验证数据库连接分开做避免两个变量互相干扰。如果你在调 Django 服务的同时还要接大模型能力比如让模型帮你分析日志、生成排障建议可以先把模型侧的 Key 和接入方式准备好这样排障脚本里能顺手调用。TaoToken 的入口在这里注册后到控制台拿 Key官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content控制台拿 Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteAPI 基地址统一用https://taotoken.net/api这个不加 UTM。如果你只是想快速验证模型通不通用模型对话页面最省事模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite长期跑编码类任务、Agent 类任务的话Coding Plan 更合适Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewriteClaude Code 相关接入看这个ClaudeCodeAnthropichttps://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecode-anthropicutm_campaignrewrite注意模型接入和数据库连接是两条独立的链路。排障时先保证数据库这条链路稳定再去验证模型输出否则日志里两类错误混在一起很难定位。4. 可复制配置settings 骨架 close_old_connections 调用时机4.1 数据库配置骨架先给一份可以直接抄的 Djangosettings.py数据库配置。关键参数是CONN_MAX_AGE和CONN_HEALTH_CHECKS# settings.py DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: your_db, USER: your_user, PASSWORD: your_password, HOST: 127.0.0.1, PORT: 3306, CONN_MAX_AGE: 60, # 连接最长复用 60 秒别设太大 CONN_HEALTH_CHECKS: True, # Django 3.1 复用前做健康检查 OPTIONS: { charset: utf8mb4, connect_timeout: 5, read_timeout: 30, write_timeout: 30, }, } }几个参数的含义对照参数作用建议值CONN_MAX_AGE连接复用秒数0 表示每请求关闭30~60别超过中间设备 idle 超时CONN_HEALTH_CHECKS复用前 ping 一下连接是否可用TrueDjango 3.1connect_timeout建连超时5read_timeout读超时30write_timeout写超时30CONN_HEALTH_CHECKS True是很多人忽略的关键项。开了它之后Django 在复用连接前会做一次轻量检查发现连接死了就重建能挡掉相当一部分 InterfaceError。但注意它只在标准请求周期里生效Celery、线程、脚本里还是得手动调close_old_connections。4.2 close_old_connections 的正确调用时机先看最小可复现的修复写法也就是你贴的那段import django.db django.db.close_old_connections() print(list(django.contrib.auth.models.User.objects.all()))但每次用 model 前都手动调不是长久之计容易漏。正确做法是分场景场景一Celery 任务。用信号在任务前后自动清理# your_app/celery_signals.py from celery.signals import task_prerun, task_postrun from django.db import close_old_connections task_prerun.connect def _close_before_task(**kwargs): close_old_connections() task_postrun.connect def _close_after_task(**kwargs): close_old_connections()场景二自定义后台线程 / 长轮询。在线程循环里每轮开始前调一次import time from django.db import close_old_connections def worker_loop(): while True: close_old_connections() # 每轮先清理失效连接 try: do_something_with_orm() except Exception as e: logger.exception(worker error: %s, e) time.sleep(5)场景三管理命令 / 定时脚本。在入口处调一次即可# management/commands/run_sync.py from django.core.management.base import BaseCommand from django.db import close_old_connections class Command(BaseCommand): def handle(self, *args, **options): close_old_connections() # 你的业务逻辑场景四中间件兜底。如果你不确定哪些路径会漏加个中间件在请求进入时清理# your_app/middleware.py from django.db import close_old_connections class CloseOldConnectionsMiddleware: def __init__(self, get_response): self.get_response get_response def __call__(self, request): close_old_connections() response self.get_response(request) close_old_connections() return response然后在settings.py的MIDDLEWARE里加上your_app.middleware.CloseOldConnectionsMiddleware。提示Django 标准请求周期本身已经会在请求开始/结束调用close_old_connections所以普通视图一般不用额外加。真正需要手动调的是不走请求周期的那些执行体Celery、线程、脚本、WebSocket consumer。4.3 顺手把模型接入配置也放进来如果你排障脚本里要调模型分析日志可以放一份settings.json风格的配置骨架非 Django settings是给脚本/工具用的{ taotoken: { base_url: https://taotoken.net/api, api_key: sk-你的key, model: claude-sonnet-4-5, timeout: 60 }, database: { conn_max_age: 60, conn_health_checks: true, close_old_connections_before_use: true } }调用侧示例import json import requests cfg json.load(open(settings.json))[taotoken] resp requests.post( f{cfg[base_url]}/v1/messages, headers{ x-api-key: cfg[api_key], anthropic-version: 2023-06-01, content-type: application/json, }, json{ model: cfg[model], max_tokens: 512, messages: [{role: user, content: 帮我分析这段 Django 报错}], }, timeoutcfg[timeout], ) print(resp.status_code, resp.text[:200])5. 复现步骤与验证确认修复真的生效光改代码不算数得能复现、能验证。下面这套流程我实测下来比较稳。5.1 复现 InterfaceError第一步把 MySQL 的wait_timeout临时调小加速复现SET GLOBAL wait_timeout 30; SET GLOBAL interactive_timeout 30; SHOW VARIABLES LIKE %timeout%;第二步写一个脚本先查一次库然后 sleep 超过 30 秒再查一次import time import django import os os.environ.setdefault(DJANGO_SETTINGS_MODULE, your_project.settings) django.setup() from django.contrib.auth.models import User print(first query:, list(User.objects.all()[:1])) time.sleep(40) # 超过 wait_timeout print(second query:, list(User.objects.all()[:1])) # 这里大概率炸第三步运行它你会看到第二次查询抛pymysql.err.InterfaceError: (0, )。这就复现成功了。5.2 验证修复在第二次查询前加上close_old_connections()import time import django import os os.environ.setdefault(DJANGO_SETTINGS_MODULE, your_project.settings) django.setup() from django.db import close_old_connections from django.contrib.auth.models import User print(first query:, list(User.objects.all()[:1])) time.sleep(40) close_old_connections() # 关键清理失效连接 print(second query:, list(User.objects.all()[:1])) # 应该正常返回预期结果第二次查询正常返回数据不再抛 InterfaceError。如果还是炸往下看排障章节。5.3 用连接状态辅助验证想更直观地看连接有没有被重建可以在查询前后打印连接 idfrom django.db import connection, close_old_connections print(conn id before:, id(connection.connection)) close_old_connections() print(conn id after:, id(connection.connection))如果close_old_connections真的关掉了旧连接connection.connection会变成None下次查询时重建id 会变。这能帮你确认清理逻辑确实执行了。6. 本篇常见错排查清单改完还报错的话按下面顺序排查基本能覆盖 90% 的情况。排查一CONN_MAX_AGE 设太大。如果你设了 3600 甚至更大而中间设备 300 秒就断那连接必然失效。把CONN_MAX_AGE降到比中间设备 idle 超时更小的值比如 60。这是最常见的坑。排查二CONN_HEALTH_CHECKS 没开。Django 3.1 以下没有这个参数3.1 建议开。开了之后标准请求周期能自动挡掉失效连接。检查你的 Django 版本python -c import django; print(django.get_version())排查三Celery 没接信号。Celery worker 是常驻进程不走请求周期必须用task_prerun/task_postrun信号调close_old_connections。很多人只改了视图忘了 Celery结果任务里照样炸。排查四多线程共享连接。Django 的数据库连接是线程绑定的close_old_connections只清理当前线程的连接。如果你自己开了线程池每个线程都要各自调。别在线程间传 connection 对象。排查五连接被中间件/代理断掉。云数据库代理、K8s Service、NAT 网关都可能有更短的 idle 超时。这种情况除了调小CONN_MAX_AGE还可以在 MySQL 侧开tcp_keepalive或者用连接池中间件如 ProxySQL管理连接。排查六错误码不是 0 的 InterfaceError。如果错误码不是(0, )而是别的比如(2006, MySQL server has gone away)那可能是包太大或查询超时方向不同。(0, )基本就是连接已断。排查七改了没生效。确认你改的是运行环境实际加载的 settings容器里可能有多个 settings 文件或者环境变量覆盖了配置。打印一下实际生效的值from django.conf import settings print(settings.DATABASES[default].get(CONN_MAX_AGE)) print(settings.DATABASES[default].get(CONN_HEALTH_CHECKS))排查八close_old_connections 调了但没关。它只在连接过期或不可用时才关。如果你刚建完连接立刻调它不会关。想强制关可以显式connection.close()但一般不需要。最后补一个我踩过的坑close_old_connections不是万能的它解决的是连接失效后没被清理的问题。如果你的服务本身连接泄漏比如手动开了 cursor 没关、事务没提交那得从代码层面修。排障时先看 MySQL 的SHOW PROCESSLIST确认连接数是不是异常增长再决定是清理策略问题还是泄漏问题。数据库连接这块稳定之后如果你还要接模型做日志分析或自动化排障回到前面 TaoToken 的接入文档和 API Keys 页面把 Key 配好用https://taotoken.net/api作为基地址就能跑通。两条链路各自验证、互不干扰排障效率会高很多。