debugtoolbar 在 sublime text 中不显示慢查询标记是因为未配置 sql_warning_threshold 或阈值过高；需在 settings.py 中显式设置（如 {"sql_warning_threshold": 50}），且 sublime 必须以项目根目录打开才能正确跳转到 origin 行。
DebugToolbar 为什么在 Sublime Text 里看不到慢查询标记
因为 DEBUG_TOOLBAR_CONFIG["SQL_WARNING_THRESHOLD"] 没设，或者设了但值太高（比如默认不设就等于没阈值）。DebugToolbar 只记录耗时、不自动标红标黄——它不是“慢查询检测器”，只是“查询记录仪”。你得手动告诉它：“超过多少毫秒算慢”。
常见错误现象：SQL 面板里每条语句都显示 0.8ms 或 12.3ms，但全都是白底黑字，没警告色；点开也看不到“⚠️ Slow query”提示。
- 必须在
settings.py中显式写死阈值，例如：DEBUG_TOOLBAR_CONFIG = {"SQL_WARNING_THRESHOLD": 50}（单位毫秒） - 这个值对所有数据库连接生效，
multi-db场景下无法按库区分 - SQLite 或某些第三方 backend（如
django-mssql-backend）可能返回0.0ms，导致阈值失效——换用 PostgreSQL/MySQL 官方驱动更可靠
Sublime Text 里怎么快速跳转到触发慢查询的 Python 行
DebugToolbar 的 SQL 面板每条记录底部有 “Origin” 字段，但默认只显示文件名+行号（如 views.py:42），不带完整路径。Sublime Text 打开项目时若没把根目录设对，点击跳转会失败或打开空白页。
使用场景：你在 Sublime Text 里按 Ctrl+P 搜索 views.py，结果发现跳转后光标停在第 1 行，不是第 42 行。
- 确保
DEBUG_TOOLBAR_CONFIG["SHOW_TEMPLATE_CONTEXT"] = True，这样 Origin 才会带准确行号 - Sublime Text 必须以项目根目录为工作区打开（右键 →
Open Folder as Project），否则相对路径解析失败 - 如果仍跳转不准，复制 Origin 文本（如
myapp/views.py:87），在 Sublime Text 中按Ctrl+P输入@87强制跳转到该行 - 注意：QuerySet 懒加载会导致 Origin 显示在
list()、for循环或模板渲染处，而非.filter()定义处——得顺着调用栈往回查
为什么 Sublime Text 里搜 select_related 却没找到 N+1 问题源头
因为 DebugToolbar 的 SQL 面板只列原始语句，不自动聚类分析。它把 10 条几乎一样的 SELECT * FROM user WHERE id = %s 当成 10 条独立查询，不会合并提示“重复查询 10 次”。
容易踩的坑：你在 Sublime Text 全局搜索 select_related，发现用了，就以为没问题；结果 DebugToolbar 显示 12 条相似 SQL，实际是 prefetch_related 没配对、或外键字段在模板里被循环访问触发了隐式查询。
- 重点看 SQL 面板里的
Duplicates列数值 —— 不是靠搜代码，而是靠数面板里相同 pattern 出现次数 - 模板中写
{{ obj.foreign_field.name }}且没select_related，比直接写obj.foreign_field更隐蔽，更容易漏查 -
QuerySet.explain()返回的是数据库执行计划，不是 Django 层调用链；想定位 Python 层哪行触发，得结合 DebugToolbar 的 “Call Stack” 小图标（需开启ENABLE_STACKTRACES = True）
生产环境不能开 DebugToolbar，Sublime Text 还能做什么
不能依赖 DebugToolbar，但 Sublime Text 仍是排查利器——关键在于提前埋点、结构化日志、快速 grep。
性能 / 兼容性影响：DebugToolbar 本身会增加单请求内存占用（约 2–5MB），且依赖 DEBUG=True，生产环境禁用是硬性要求。但你可以用它生成的 SQL 模板反向构建日志分析规则。
- 在开发环境用 DebugToolbar 抓出典型慢 SQL，复制其
sql字段（如SELECT "auth_user"."id", ... FROM "auth_user" WHERE "auth_user"."is_active" = %s），存为 Sublime Text 的 snippet 或 grep 模板 - 配合 Django 日志配置：
'django.db.backends': {'level': 'DEBUG'}，把 SQL 写进文件；之后用 Sublime Text 打开日志，Ctrl+F搜duration:，再按Ctrl+Shift+L提取所有耗时数字，排序找 Top 10 - 写个简单正则：
duration:\s+(\d+\.\d+)ms，用 Sublime Text 的 “Find All in Files” 扫描整个项目日志目录，比写脚本更快 - 注意：
connection.queries在生产环境不可靠（线程不安全），别试图在 view 里实时 dump 它——日志才是唯一可信来源
真正卡住人的往往不是某条 SQL 多慢，而是同一段逻辑在不同请求里忽快忽慢；这时候得看日志里 duration 的波动范围，而不是单次峰值——Sublime Text 的多行选择和列编辑功能，比任何监控面板都更适合干这事。
