直接用 cprofile 包裹可疑视图函数最准：开头 pr.enable()、结尾 pr.disable() 并 dump_stats，再用 snakeviz 分析；避免全局 profile 或 runserver 整体采样。
怎么快速定位 Django 视图里哪个函数最拖慢响应
直接用 cProfile 包裹视图函数，比改 settings 或加全局中间件更快、更准——尤其当你只怀疑某个 API 或页面时。
常见错误是直接对整个 as_view() 结果 profile，结果堆栈太深、噪音太多；或者用 python -m cProfile 跑 manage.py runserver，根本捕不到单次请求的上下文。
- 在视图函数开头加：
import cProfile pr = cProfile.Profile() pr.enable()
- 结尾加：
pr.disable() pr.dump_stats('/tmp/view_profile.prof') - 用
snakeviz查看：snakeviz /tmp/view_profile.prof（别用pstats命令行，函数调用链太难读） - 注意：不要在生产环境长期开着，
cProfile有 5–10% 的 CPU 开销；开发机上单次分析足够
Django ORM 慢查询没报错但页面卡顿，怎么抓出真实 SQL
靠 django.db.connection.queries 只能看到已执行的 SQL，但查不出 N+1 或重复查询——它不记录“本该合并却没合并”的逻辑漏洞。
真正有效的做法是开启 django-debug-toolbar 的 SQLPanel + 启用 EXPLAIN（PostgreSQL/MySQL 支持），或直接用数据库日志反推。
- 在
settings.py中确保：DEBUG = True且'debug_toolbar.middleware.DebugToolbarMiddleware'在中间件列表靠前位置 - 在浏览器打开调试栏后，点 SQL 面板，重点关注“Duplicates”和“Similar queries”两列——它们标出重复执行的相同 SQL
- 如果用了
select_related()却还是出现多条SELECT ... FROM auth_user，大概率是外键字段没在values()或only()里显式声明，ORM 自动 fallback 到懒加载 - PostgreSQL 用户可加
LOG_MIN_DURATION_STATEMENT = 100到数据库配置，直接从 pg_log 抓 >100ms 的语句，比应用层更可信
用 Silk 中间件分析慢请求，为什么有些接口压根不显示
Silk 默认只记录 2xx 和 3xx 响应，400/500 错误请求默认被过滤——这是最常被忽略的配置点。
另一个坑是 SILKY_INTERCEPT_PERCENT 设成 100 也不代表 100% 记录，它受 SILKY_MAX_RECORDED_REQUESTS 缓存上限限制，请求一多就自动丢旧的。
- 强制记录所有请求（含错误）：在
settings.py加SILKY_INTERCEPT_PERCENT = 100和SILKY_IGNORE_PATHS = []，再设SILKY_MAX_RECORDED_REQUESTS = 10000 - 如果用了 Gunicorn/UWSGI，确保
SILKY_PYTHON_PROFILER = True且SILKY_META = True，否则看不到 Python 函数耗时分解 - Silk 的 “Timeline” 视图里，灰色长条不是空闲时间，而是该请求中未被 Silk hook 到的代码段（比如信号 handler、celery task 同步调用）——别误以为是数据库等待
cProfile 和 Silk 数据对不上，哪个更可信
cProfile 测的是纯 Python 执行时间，Silk 测的是 WSGI 层到响应写出的全链路（含模板渲染、中间件、DB 连接池等待）。两者维度不同，不是谁替代谁的关系。
典型矛盾场景：cProfile 显示 render_to_string 占 80ms，Silk 却显示整个请求耗时 1200ms——说明瓶颈其实在 DB 查询或网络 IO，而 cProfile 因为没 hook 底层 C 扩展（如 psycopg2 的 execute），把等待时间算进了“空闲”。
- 先看 Silk 的 “SQL Queries” 和 “Python Profiler” 两个标签页是否都打开；如果 Python Profiler 为空，说明
SILKY_PYTHON_PROFILER = False或没装py-spy兼容包 - 对比时盯住同一请求的 Request ID（Silk 里叫
request_id，cProfile 输出里没有，得自己打日志补） - 真正卡顿往往藏在
time.sleep()、requests.get()、cache.get()这类阻塞调用里——cProfile 不会显示它们耗时，Silk 会，但得确认你没在中间件里提前 return 了
查性能不是比数字大小，是看时间花在哪一层：DB？模板？序列化？还是外部 HTTP？每层得用对应工具戳，混着看只会更糊涂。
