直接重写save()方法做日志不可靠，因无法捕获bulk_create、bulk_update、raw sql更新及外键反向操作等场景，导致漏记；信号机制虽官方推荐，但post_save在事务提交前触发易产生幽灵日志，post_delete中实例字段不可查，且信号无请求上下文，须配合transaction.on_commit()、threading.local（或contextvars）及合理字段筛选才能确保日志准确、安全、高效。

如何实现django项目的操作日志审计_通过python信号机制监听模型变化

为什么直接重写 save() 方法做日志不可靠

因为 save() 不会捕获 bulk_create、bulk_update、raw SQL 更新、外键反向操作（比如 user.profile.delete()）等场景，日志必然漏记。信号机制是 Django 官方推荐的模型变更监听方式，但必须避开几个典型陷阱。

post_save 信号在事务提交前触发，如果后续事务回滚，日志记录就变成“幽灵日志”——实际数据没变，日志却写了
pre_delete/post_delete 拿不到被删对象的字段值（post_delete 中实例已从 DB 解绑，pre_delete 可用但需手动查一次 DB）
信号接收器里不能依赖 request 对象——它根本不在信号调用栈里，Django 信号是纯模型层的，和 HTTP 请求无绑定

用 django.db.transaction.on_commit() 确保日志与数据一致

这是解决“幽灵日志”的核心。所有审计日志写入必须延迟到事务真正提交之后执行，否则日志和 DB 状态不一致。

from django.db import transaction
from django.db.models.signals import post_save, post_delete
<p>def log_model_change(sender, instance, created, **kwargs):</p><h1>不在这里直接写日志</h1><pre class="brush:python;toolbar:false;">transaction.on_commit(lambda: _write_audit_log(sender, instance, 'create' if created else 'update'))

def log_model_delete(sender, instance, **kwargs):

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

删除前先序列化关键字段，因为 post_delete 里 instance 已不可查

data = {f.name: getattr(instance, f.name) for f in instance._meta.fields}
transaction.on_commit(lambda: _write_audit_log(sender, data, 'delete'))

务必用 transaction.on_commit() 包裹日志写入逻辑，而不是直接调用
post_delete 信号中，instance 的字段仍可读（只要没被显式 del 或 reload），但不能做任何 DB 查询（如 instance.related_set.all()）
避免在 lambda 里引用闭包中可能变化的变量；建议提前提取必要字段，如上面的 data 字典

如何记录谁在什么时间做了什么操作

信号本身不带用户上下文，必须从请求线程中“借”出当前用户。推荐用 threading.local + 中间件注入，而非依赖全局变量或信号参数传参（后者破坏解耦）。

# middleware.py
import threading
_local = threading.local()
<p>class AuditLogMiddleware:
def <strong>init</strong>(self, get_response):
self.get_response = get_response</p><pre class="brush:python;toolbar:false;">def __call__(self, request):
    _local.user = getattr(request, 'user', None)
    _local.request_id = getattr(request, 'id', None)
    response = self.get_response(request)
    # 清理，防止线程复用导致污染
    if hasattr(_local, 'user'):
        delattr(_local, 'user')
    if hasattr(_local, 'request_id'):
        delattr(_local, 'request_id')
    return response

在信号处理器中取：

def _write_audit_log(model_class, data, action): user = getattr(_local, 'user', None) user_id = user.pk if user and hasattr(user, 'pk') else None

写入 AuditLog model...

中间件必须放在 AuthenticationMiddleware 之后，否则 request.user 是 AnonymousUser 或未认证状态
threading.local 在异步视图（ASGI）中不生效，Django 4.1+ 应改用 contextvars.ContextVar
不要试图在信号里调用 get_current_request() 这类“黑魔法”，它不稳定且难以测试

哪些字段该记、哪些不该记、怎么避免性能崩掉

审计日志不是全量 dump，重点是“谁、何时、对哪条记录、做了什么变更”。字段选择直接影响磁盘和查询性能。

必记：模型名（instance._meta.label）、主键值（instance.pk）、操作类型（create/update/delete）、操作时间（timezone.now()）、操作人 ID
慎记：大文本字段（如 TextField）、二进制字段（BinaryField）、JSON 字段（除非只记 diff 后的 key 列表）
更新操作要对比新旧值——用 model_to_dict(instance) + 从数据库 reload 旧值（仅对单条记录），或监听 pre_save 存快照（注意内存开销）
高频写模型（如访问统计、实时消息）禁用审计信号，要么跳过，要么走异步任务（Celery）延后处理