重写Django模型save方法后哪些场景下不会触发？如何优化字段自动更新？

一、不会触发模型save()的常见场景 #

Django运行过程中存在大量绕开自定义模型save()方法的操作，这也是你遇到“数据达标但状态未更新、手动在Admin保存才生效”的核心原因，常见场景包括：

• QuerySet级别的批量操作：调用QuerySet.update()、bulk_create()、bulk_update()时，Django会直接生成原生SQL在数据库层执行，全程不会加载生成对应的模型实例，自然不会触发实例的save()逻辑。尤其当你用F表达式做计数增量更新时，比如执行Log.objects.filter(agent=xxx).update(calls_logged=F('calls_logged') + 1)，这类操作是当前bug的最高概率来源——呼叫量、短信量的累加如果走这个接口，哪怕数值累计超过阈值，自定义的save()逻辑也永远不会被触发，只有手动加载实例保存时，才会执行判断更新状态。
• 原生SQL执行操作：通过connection.cursor()执行手写的增删改语句修改对应数据表时，完全绕过ORM层的所有逻辑，自然不会触发save()。
• ORM快捷方法的默认更新分支：比如update_or_create()命中更新逻辑时，默认通过QuerySet.update()完成修改，同样不会触发对应实例的save()方法。

二、当前实现的潜在漏洞 #

除了save()逻辑被绕开的问题，现有重写的save()流程本身也存在缺陷：

• 状态判断逻辑不闭环：当前代码只会在满足阈值时把completed_logs设为True，如果后续计数被调低到阈值以下，completed_logs不会自动改回False，长期运行会出现数据偏差。
• 逻辑耦合脆弱：把状态判断完全绑定在save()流程上，只要有任何一处字段修改没走save()流程，就会出现数据不一致。

三、更稳定的派生字段实现思路 #

根据completed_logs的实际使用需求，可以选择适配的优化方案：

• 如果不需要对completed_logs做数据库索引、复杂过滤查询：直接将其改为模型属性即可，不需要占用数据库存储，也永远不会出现数据不一致问题：

  @property
  def completed_logs(self):
      return self.calls_logged >= 30 and self.texts_logged >= 50
  

• 如果需要保留completed_logs的数据库索引、支持过滤查询：
  • 统一封装业务操作入口：不要在代码各处散落直接修改calls_logged、texts_logged的ORM调用，而是在模型层面封装专门的计数更新方法，比如add_call_record()、add_text_record()，所有计数更新操作必须走这些方法，在方法内部同步完成completed_logs状态的判断和更新，从根源上避免逻辑漏写。
  • 批量操作同步对齐逻辑：如果业务场景必须使用批量更新接口，需要在对应的update语句里同步带上completed_logs的计算逻辑，不要只单独更新计数字段。
  • 增加兜底校验：对这类计数派生的状态字段，可以搭配低频次的定时任务扫描数据表，把状态不符合规则的记录批量修正，避免长期累积的数据偏差。

内容的提问来源于stack exchange，提问作者John R Perry