django 自带 admin 日志仅记录后台操作且不可扩展，需通过中间件捕获请求上下文并配合 process_view、process_exception、process_response 三阶段记录审计日志，结合带索引的 auditlog 模型（含 user、path、method、status_code、object_repr、changes）实现可追溯变更审计。
为什么 Django 自带的 django.contrib.admin 日志不够用
它只记录 admin 后台的操作，且字段固定、不可扩展，比如你用 API 修改用户邮箱，或者在自定义视图里调用 user.save()，这些完全不会进 DjangoAdminLog 表。真正要审计的是“谁在什么时候、通过什么接口、改了哪个对象的哪些字段”，得自己抓请求生命周期。
用中间件捕获请求上下文的关键点
中间件是唯一能稳定拿到 request.user、request.path、request.method 且不侵入业务逻辑的位置。但要注意：不能在 process_request 里直接写日志，因为此时响应还没生成，你不知道操作是否成功；也不能等到 process_response 再记——万一视图抛了异常，process_response 根本不执行。
- 必须用
process_view+process_exception+process_response三者配合：在process_view记下“准备做什么”，在后两者中补全“结果”和“异常信息” -
request对象在中间件链中是共享的，可以往request.audit_log_data = {...}里塞临时数据，避免闭包或线程局部变量出错 - 别在中间件里做耗时操作（如查数据库、发 HTTP 请求），日志写入建议异步（用
threading.Thread或asyncio.to_thread）或丢进消息队列，否则拖慢所有请求
AuditLog 模型该存哪些字段才实用
光记 URL 和用户 ID 没用，查问题时你真正需要的是“谁改了订单状态？从 pending 变成了 shipped？”。所以字段设计要围绕可追溯性：
-
user：外键到User，允许为NULL（匿名请求或定时任务） -
path：CharField(max_length=255)，存request.path，别存完整 URL（含域名、参数易变） -
method：CharField(max_length=10)，如"POST"、"PATCH" -
status_code：PositiveSmallIntegerField()，区分成功/失败 -
object_repr：TextField()，存被操作对象的字符串表示（如"Order #12345"），不要存 ID 而不带类型 -
changes：JSONField()，记录关键字段变更，格式如{"status": ["pending", "shipped"]}，不是所有字段都记，只记业务敏感字段
怎么避免日志爆炸和性能崩盘
一个用户点一次“提交订单”，可能触发多个 ORM save、信号、缓存更新，如果每个都记一条日志，一天就几百万条，查询和清理都成问题。
- 加白名单控制：只对特定路径（如
/api/v1/orders/、/admin/）或特定方法（POST、PATCH、DELETE）记录，GET 查数据一般不审计 - 跳过静态文件和健康检查：在中间件开头判断
request.path.startswith(("/static/", "/healthz"))直接 return - 用
bulk_create批量写入，而不是每次请求都save()一次；或者先写本地文件/Redis，再由后台进程异步落库 - 注意
JSONField在 MySQL 5.7+ 才原生支持，旧版本得用TextField+json.dumps，且无法做 JSON 查询
最常被忽略的是：没给 user 字段加数据库索引，查某个人的所有操作时直接全表扫描。还有人把 changes 当作文本搜关键词，结果发现 MySQL 的 LIKE "%status%" 完全走不了索引——真要查变更内容，得额外建全文索引或用 Elasticsearch。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
