不能在事务内直接调用 task.delay()，因为其会立即发消息到 Broker，而事务可能未提交或回滚，导致数据不一致；应使用 transaction.on_commit() 在提交后触发任务。
为什么不能在事务内直接调用 task.delay()
因为 Celery 任务一旦调用 task.delay()，就会立刻序列化参数、发消息到 Broker（如 Redis/RabbitMQ），而此时 Django 数据库事务可能还没提交。如果事务后续回滚，Celery 任务却已执行，就会造成数据不一致——比如用户注册成功前就发了欢迎邮件，结果注册因异常被 rollback，邮件却发出去了。
常见错误现象：IntegrityError 在 Celery worker 中抛出（查不到刚创建的记录）、任务逻辑读到旧数据、或者任务根本查不到目标对象。
- 事务未提交时，新记录对其他数据库连接（包括 Celery worker）不可见
-
task.delay()是同步发消息，不等待事务状态 - 即使用了
transaction.on_commit()，也必须确保它在事务 commit 前注册，且不能包裹在 try/except 吞掉异常后的位置
用 transaction.on_commit() 注册任务是最可靠方式
Django 提供的 transaction.on_commit() 会在当前事务成功提交后立即执行回调函数，天然规避了“事务未提交就发任务”的问题。它只在 atomic block 内有效，且仅对成功的 commit 触发。
实操要点：
立即学习“Python免费学习笔记（深入）”；
- 必须在
@transaction.atomic或with transaction.atomic():代码块内调用transaction.on_commit() - 回调函数里再调用
task.delay()，不要提前调用 - 避免在回调中做耗时操作或 DB 查询——它运行在 Web 请求线程，只是延迟到 commit 后执行
- 如果事务嵌套，
on_commit()绑定的是最外层事务
示例：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
from django.db import transaction from myapp.tasks import send_welcome_email <p>def create_user_and_notify(username, email): with transaction.atomic(): user = User.objects.create(username=username, email=email)</p><h1>✅ 正确：注册回调，等 commit 后再触发</h1><pre class="brush:php;toolbar:false;"><code> transaction.on_commit(lambda: send_welcome_email.delay(user.id))
别用 post_save 信号替代 on_commit
post_save 信号在 save() 方法结束时触发，但此时事务未必已提交——尤其在批量操作或嵌套 atomic 块中，信号可能在 commit 前就发出。很多开发者误以为“保存完了就安全了”，结果踩坑。
典型陷阱场景：
- 视图里用
transaction.atomic创建多个对象，其中某个post_save触发了 Celery 任务，但事务最终 rollback - 使用
bulk_create时，post_save根本不触发，导致任务漏发 - 信号处理函数里又开了新事务，干扰原有上下文
除非你明确控制信号只在 commit 后发送（例如自己封装 signal + on_commit），否则不要依赖 post_save 来解耦异步任务。
复杂业务中要注意任务参数的“可序列化”和“时效性”
transaction.on_commit() 回调里的 lambda 或闭包，捕获的是 commit 前的对象状态。如果传的是模型实例（如 user），Celery 任务反序列化时会尝试重新查询，但此时若该记录已被删除或修改，就会出错或读到脏数据。
- ✅ 推荐传主键（如
user.id），任务内部再User.objects.get(id=...) - ❌ 避免传整个 model 实例、
QuerySet或带缓存属性的对象（如user.profile） - 如果必须传计算结果（如邮箱模板内容），确保它不依赖未提交的数据状态
- 考虑加一层任务重试机制（
autoretry_for），应对短暂查询失败
容易被忽略的一点：Django 的 on_commit 不保证回调执行顺序，也不捕获回调异常——如果 lambda 抛错，Web 请求不会感知，日志里也难追踪。建议在回调里加简单日志或 Sentry 上报。
