如何实现Django post_save信号仅在User表新建记录时触发

你的性能问题本质是高频更新场景下的无效信号调度开销：每次请求更新last_login、last_active字段时，Django都要走完整的信号分发流程、调用你的handler函数，哪怕函数里只做了if created的判断就返回，百万级QPS下这部分重复调用的开销会被持续放大。
以下是按性能优先级排序的可行方案： #

方案1：重写模型save方法（性能最优，无额外调度开销） #

信号适合跨模块的松耦合场景，如果你的新建用户逻辑不需要给第三方应用留扩展点，完全没必要用信号，直接重写User模型的save方法，从根源上避免更新场景的多余逻辑执行：

from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    def save(self, *args, **kwargs):
        # 保存前判断是否为新记录：无主键即为待插入的新数据
        is_new = self.pk is None
        super().save(*args, **kwargs)
        # 仅新记录插入完成后执行对应逻辑
        if is_new:
            # 替换为你的实际业务逻辑
            print(f"$$$$$$$$$$$ User created: {self}")

如果你已经在项目中使用Django默认的User模型、没有做自定义用户模型，直接用方案2即可，不需要强行迁移用户表。

方案2：保留信号，前置短路过滤高频更新场景（改造成本最低） #

如果必须保留信号实现（比如需要兼容现有代码结构、保持逻辑解耦），可以利用Django的更新特性：每次请求更新last_login、last_active字段时，都会在save时传入update_fields参数指定仅更新这两个字段，你可以在handler最开头直接过滤这类场景，几乎无额外性能损耗：

@receiver(post_save, sender=User, dispatch_uid="call_method")
def call_method(sender, instance, created, update_fields=None, **kwargs):
    # 提前返回：如果是仅更新last_login/last_active的高频请求，直接终止流程
    if not created and update_fields and {"last_login", "last_active"}.issuperset(update_fields):
        return
    
    # 后续逻辑仅在新建用户、或更新其他字段时执行
    if created:
        print(f"$$$$$$$$$$$ User created: {instance}")
        # 替换为你的实际业务逻辑

这个方案的额外开销只有一次简单的集合判断，相比原来每次请求都完整执行信号handler的逻辑，性能提升非常明显，完全能支撑高并发场景。 #

方案3：数据库层INSERT触发器（极致性能场景可选） #

如果你的新建用户逻辑不依赖Django ORM的上下文（比如只是写入统计日志、发送异步消息），可以直接在数据库层面为User表配置AFTER INSERT触发器，逻辑完全在数据库层执行，不占用应用服务器资源，性能是所有方案里最高的。缺点是业务逻辑和应用代码分离，后续维护成本更高，仅建议对性能有极致要求时使用。 #

注意 #

Django本身没有提供「仅插入时触发」的内置信号，所有第三方库实现的类似能力，本质都是在信号分发层做了和上面方案2一样的判断逻辑，不会带来额外的性能提升，没必要额外引入依赖。 #

内容的提问来源于stack exchange，提问作者MOHAMED AZARUDEEN