关键是在process_request中用time.perf_counter()记录请求开始时间到request._start_time，process_response中计算耗时并记录日志；异常时需在process_exception中兜底记录，且必须使用logging而非print，确保每条请求耗时日志包含path、method、status_code和elapsed。
中间件里怎么获取请求开始和结束的时间点
关键是在 process_request 和 process_response 两个方法里打时间戳。Django 中间件的生命周期保证了这两个方法一定会成对调用（除非异常中途退出，后面会说怎么兜底）。process_request 在视图执行前触发，process_response 在视图返回后、响应发出前触发。
别用 time.time() 粗粒度计时——它受系统时钟调整影响，且精度不够。改用 time.perf_counter()，它是单调递增的高精度计时器，适合测耗时。
- 在
process_request中存一个浮点数到request对象上：request._start_time = time.perf_counter() - 在
process_response中读取并计算：elapsed = time.perf_counter() - request._start_time - 如果中间件链里有其他中间件抛出异常，
process_response不会执行。得补上process_exception方法，同样读request._start_time计算耗时
如何把耗时写进日志而不是 print 或 console
直接 print() 在生产环境不可控，也难过滤。应该走 Python 标准 logging 模块，并配好 name 和 level。
建议用 logger = logging.getLogger(__name__)，这样日志能带上模块路径，方便定位。级别设为 INFO，避免淹没在 DEBUG 海量日志里；但若想观察慢请求，可对超过阈值（比如 500ms）的请求升为 WARNING。
立即学习“Python免费学习笔记（深入）”；
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
- 日志格式里必须包含
request.path、request.method、状态码response.status_code和elapsed - 别漏掉异常路径：在
process_exception里也要记录，此时response是None，状态码默认记为500 - 避免在日志里拼接敏感字段（如
request.GET全部内容），尤其涉及用户 ID 或 token
Django 3.1+ 的新式中间件写法要注意什么
老式中间件类要实现一堆 process_* 方法，容易漏写。Django 3.1 引入了基于 callable 的函数式中间件，更轻量、更易测试。
函数签名是 def timing_middleware(get_response):，返回一个闭包函数，该函数接收 request，内部手动调用 get_response(request)，并在前后插计时逻辑。这种方式天然规避了 process_exception 的遗漏问题——因为你在 try/except 里包裹了 get_response()。
- 闭包里定义
logger，避免每次调用都重新getLogger - 捕获异常后仍要记录耗时，再 re-raise，否则 Django 就收不到异常去渲染 500 页面
- 注意不要在中间件里做阻塞操作（如发 HTTP 请求、查 DB），否则会拖慢所有请求
为什么有些请求耗时记录为负数或极小值
出现负数基本是因为 request._start_time 没被设置，或者被其他中间件覆盖/清空。极小值（比如 0.000001s）通常是静态文件（由 django.views.static.serve 处理）或健康检查接口，它们不经过完整视图逻辑，可能绕过部分中间件。
- 检查中间件注册顺序：
MIDDLEWARE列表里你的计时中间件必须靠前，确保第一个捕获process_request - 确认没在别的地方删了
request._start_time属性（比如某些安全中间件会清理 request 属性） - 开发环境下开启
DEBUG=True时，Django 自带的DebugToolbarMiddleware可能干扰计时，上线前务必关掉
实际部署时，别只依赖日志文本解析来统计慢请求。如果量大，考虑把 elapsed 推到 Prometheus（用 Counter 和 Histogram 类型），或者写进结构化日志（JSON 格式）供 ELK 处理。但最基础的一条：先确保每个请求都有且仅有一条耗时日志，不丢、不错、不重复。
