django-debug-toolbar 不显示侧边栏，需确认DEBUG=True、INTERNAL_IPS包含本地IP、DebugToolbarMiddleware位置正确；SQL面板仅捕获ORM查询，原生SQL不记录，且耗时仅含DB执行时间。
django-debug-toolbar 装不上？先确认中间件和请求环境
装完 django-debug-toolbar 却看不到侧边栏，大概率是中间件没生效或请求不满足触发条件。它只在 DEBUG=True 且请求来自本地 IP（如 127.0.0.1 或 ::1）时显示，生产环境或远程访问直接隐身。
- 检查
settings.py中DEBUG = True是否真为True（别被环境变量覆盖） -
MIDDLEWARE列表里必须包含debug_toolbar.middleware.DebugToolbarMiddleware，且位置要在CommonMiddleware之后、SecurityMiddleware之前 -
INTERNAL_IPS必须显式声明，比如：INTERNAL_IPS = ["127.0.0.1", "::1"]；Docker 或 WSL 用户常漏掉::1或宿主机 IP - 用浏览器直接访问
http://127.0.0.1:8000/，别用手机扫码、Postman 或 curl —— 它依赖响应头里的Cookie和User-Agent做基础校验
SQL 查询耗时高但侧边栏没显示？检查数据库配置和查询方式
即使侧边栏出来了，SQL 面板也可能为空或不准，尤其用了原生 SQL、raw()、或数据库连接池（如 django-db-geventpool）时。
-
django-debug-toolbar只拦截 Django ORM 层的查询（QuerySet执行、save()、delete()），绕过 ORM 的connection.cursor().execute()不会记录 - 确保
DATABASES配置中没关掉"OPTIONS": {"disable_server_side_cursors": True}—— 否则某些 PostgreSQL 游标行为会让查询统计失效 - 如果用了
select_related()或prefetch_related()却没看到预期 JOIN，可能是字段名写错或反向关系未定义，侧边栏的 SQL 面板会如实反映你写的 ORM，不是“你以为的 SQL” - 注意
logging级别：若项目全局设了LOG_LEVEL = "WARNING"，可能压住调试日志，但不影响 toolbar 本身
为什么 SQL 面板里显示“0.2ms”，但页面实际卡 2s？
侧边栏的 SQL 时间只是数据库执行耗时，不包括网络往返、Python 层序列化、模板渲染、N+1 查询的累积效应，更不包括前端资源加载。
- 点开 SQL 面板右上角的“复制全部查询”按钮，把所有语句粘到数据库 CLI 里单独跑一遍，对比耗时 —— 如果 CLI 很快，问题就在 Django 层（比如大量
for obj in queryset:触发重复查询） - 留意面板底部的“Duplicate queries”提示，它会标出完全相同的 SQL 执行了几次，这是典型的 N+1 征兆
- 如果某次请求出现几十条相似但参数不同的查询（如
WHERE id IN (1), WHERE id IN (2)），说明prefetch_related没生效，或用了get()循环代替批量查询 - 注意“Time”列右侧的小图标：灰色时代表该查询被缓存（如用了
cache_page），实际没走 DB，但侧边栏仍会记一次（时间极短）
想看慢查询自动告警？光靠 toolbar 不够，得加日志钩子
django-debug-toolbar 是开发期辅助工具，不记录、不告警、不持久化。线上查慢 SQL 必须另配方案。
立即学习“Python免费学习笔记（深入）”；
- 在
LOGGING配置里给django.db.backends加"level": "DEBUG"，再配合django-sql-explorer或自定义中间件过滤耗时 > 100ms 的duration - 用
django.db.connection的queries列表做运行时分析，但仅限单次请求 —— 注意它不会自动清空，重复访问会累积 - 别在
__str__或property里触发 ORM 查询，toolbar 看不到这种隐式调用，但会拖慢整个响应周期 - 真正要定位瓶颈，得结合
django-silk或django-querycount这类可部署的监控组件，toolbar 只是第一双眼睛
侧边栏不是银弹，它只告诉你“哪条 SQL 慢”，但不会告诉你“为什么 ORM 生成了这条 SQL”。翻源码看 QuerySet._fetch_all() 和 sql.compiler 才是深水区。
