根本原因是middleware顺序错误或请求条件不满足：需debug=true、用户is_staff=true、internal_ips包含当前ip，且debug-toolbar中间件须在commonmiddleware之后、messagemiddleware之前。
装完为啥页面右下角没出现 debug-toolbar？
根本原因通常是 MIDDLEWARE 顺序或请求条件不满足。它只在 DEBUG=True 且请求用户是 is_staff=True 时才渲染，且必须放在所有可能修改响应内容的中间件（比如 CommonMiddleware、GZipMiddleware）之后。
- 检查
settings.py中DEBUG=True且当前登录用户有is_staff=True -
django-debug-toolbar的中间件必须在'django.middleware.common.CommonMiddleware'之后、'django.contrib.messages.middleware.MessageMiddleware'之前 - 确保
INTERNAL_IPS包含当前开发机 IP（如['127.0.0.1']），否则连 JS/CSS 都不会加载 - 如果用了 Nginx 或代理，确认
REMOTE_ADDR没被污染——有时得加'debug_toolbar.middleware.DebugToolbarMiddleware'到MIDDLEWARE最末尾再试一次
SQL 面板里显示的查询数远多于我写的 ORM 调用？
这是最常被误读的一点：debug-toolbar 统计的是最终发给数据库的 **实际 SQL 语句数**，不是 Python 层调用次数。N+1、隐式 SELECT、ORM 自动关联预取缺失、模板中触发的懒加载都会在这里暴露。
- 点开 SQL 面板 → 点「复制全部」→ 粘贴到终端执行
EXPLAIN ANALYZE，看是否走索引 - 注意每条 SQL 上方的「Origin」字段，能定位到具体哪行 Python 代码触发的（比如
views.py:42） - 模板里写
{{ obj.foreign_key.name }}却没select_related()，就会为每个对象额外发起一次查询 - 避免在循环里调用
.count()或.exists()，它们都生成独立SELECT COUNT(*)
为什么有些请求看不到 toolbar，但 /__debug__/ 路由能访问？
说明中间件生效了，但前端注入失败。常见于返回非 HTML 响应（JSON、文件下载）、响应头被篡改、或前端资源加载被拦截。
- toolbar 只对
Content-Type: text/html响应注入脚本，API 接口或HttpResponse(content_type='application/json')必然不显示 - 检查浏览器控制台是否有
Failed to load resource: net::ERR_BLOCKED_BY_CLIENT—— 广告屏蔽插件（如 uBlock）会干掉/__debug__/请求 - 如果用了
TemplateResponse或自定义中间件修改了response.content，toolbar 注入点可能失效 - 直接访问
http://127.0.0.1:8000/__debug__/sql/可手动查看 SQL 列表，不依赖右下角图标
生产环境误开了 debug-toolbar 会怎样？
不只是「性能变慢」这么简单。它会暴露完整 SQL、参数、堆栈、环境变量、甚至数据库连接信息，只要攻击者能构造 staff 用户请求，就等于把后台全盘托出。
-
INSTALLED_APPS和MIDDLEWARE中绝不能保留debug_toolbar在生产配置里 - 别用
if DEBUG:动态追加中间件——Django 启动时已编译中间件链，运行时开关无效 - 某些部署（如 Docker）会把
DEBUG=True当环境变量传入，务必在settings.py开头加硬性判断：assert not DEBUG, 'DEBUG must be False in production' - 即使只是临时开启，也必须确保
INTERNAL_IPS严格限制，且无任何 staff 用户密码泄露风险
