LaravelEloquent事务用法与ACID详解

Laravel Eloquent 事务并非由模型自身实现，而是完全依赖 DB facade（如 DB::transaction()）在数据库连接层统一管控，真正安全、简洁且符合 ACID 的做法是优先使用闭包式 DB::transaction()——它自动处理异常回滚、支持保存点模拟嵌套、语义清晰；而手动事务需严格配对 begin/commit/rollback 并实时监控 transactionLevel() 避免连接阻塞；更要警惕的是，HTTP 请求、队列任务、缓存更新、多库操作等统统游离于事务边界之外，必须通过 afterCommit()、补偿机制或最终一致性方案单独兜底——写对 transaction() 只是起点，识别并治理那些“看似顺带、实则危险”的边界操作，才是保障数据一致性的关键所在。

直接说结论：Eloquent 事务不是靠模型本身实现的，而是通过 DB::transaction() 或 DB::beginTransaction() 等底层 DB facade 控制，Eloquent 模型只是在事务上下文中执行 SQL —— 所以别在模型方法里“自己 try/catch + commit/rollback”，那不安全。

为什么 DB::transaction() 是首选方式

它自动处理回滚（哪怕抛出未捕获异常）、支持嵌套事务模拟、兼容所有 Eloquent 操作（save()、delete()、update()、关联同步等），且语义清晰。

• 内部用 try...catch 包裹，出错自动 rollback()，成功自动 commit()
• 如果事务块内调用另一个也用 DB::transaction() 的函数，Laravel 会降级为“保存点（savepoint）”，不是真正嵌套事务 —— 这是 MySQL/PostgreSQL 的限制，不是 Laravel 的 bug
• 不要在事务中做 HTTP 请求、文件写入或缓存操作，这些不会被回滚，会造成数据不一致

use Illuminate\Support\Facades\DB;

DB::transaction(function () {
    $user = User::create(['name' => 'Alice']);
    $user->posts()->create(['title' => 'First post']);
    // 任意一步失败（如验证、DB 约束、异常），整个事务回滚
});

手动控制事务时必须检查 DB::transactionLevel()

当你不能用闭包式 DB::transaction()（比如需要条件分支、复用已有连接），就得手动 beginTransaction() / commit() / rollback() —— 但这里最容易漏掉的是：事务中途再进一次 beginTransaction() 会导致层级错乱。

• 每次 DB::beginTransaction() 都会使 DB::transactionLevel() +1；commit() 或 rollback() 各减 1
• 手动事务必须配对，否则连接可能卡在“in transaction”状态，后续请求阻塞
• 建议在 finally 块里判断 DB::transactionLevel() > 0 再决定是否 rollback()，避免重复 rollback 报错

DB::beginTransaction();
try {
    Order::create(['total' => 99.9]);
    Payment::create(['amount' => 99.9, 'status' => 'pending']);
    DB::commit();
} catch (\Exception $e) {
    DB::rollback();
    throw $e;
}

DB::transaction() 不保证跨数据库或队列任务的原子性

ACID 只作用于单个数据库连接。如果你的业务涉及多个 DB（如主库写、日志库记操作）、或事务后 dispatch 一个队列任务（如发邮件、推送通知），这些操作都不在事务保护范围内。

• 队列任务一旦 dispatch 就脱离当前请求生命周期，即使事务回滚，任务仍会执行 —— 必须用 afterCommit() 显式延迟
• 多库操作无法靠单一事务保障一致性，得用 Saga 模式或最终一致性补偿
• Redis 缓存更新、S3 文件上传、第三方 API 调用，全都不受事务控制，需单独设计幂等与回退逻辑

DB::transaction(function () {
    $order = Order::create([...]);
    // ❌ 错误：事务回滚后，这个 job 依然会运行
    SendOrderEmail::dispatch($order);

    // ✅ 正确：仅当事务真正 commit 后才入队
    SendOrderEmail::dispatch($order)->afterCommit();
});

真正难的不是写 DB::transaction()，而是识别哪些操作看似“顺带”，实则游离在 ACID 边界之外 —— 日志记录、缓存失效、搜索索引更新、Webhook 推送，这些都得单独建模容错，而不是指望一个 transaction() 闭包兜底。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~