PDO::beginTransaction()易出错因需手动兜底异常、嵌套及连接断开等场景，而Laravel的DB::transaction()自动处理提交回滚，支持重试与保存点，更安全可靠。
为什么直接用 PDO::beginTransaction() 容易出错
因为事务不是“开始-提交”两步就完事：异常未捕获会漏掉 rollback()，嵌套事务没处理会报错，连接意外断开时状态不一致。PDO 本身不管理事务生命周期，全靠开发者手动兜底，一疏忽就数据不一致。
常见错误现象：PDOException: There is no active transaction（重复 commit() 或 rollback()）、SQLSTATE[HY000]: General error: 2013 Lost connection 后仍尝试提交、多层函数调用中事务中途被意外关闭。
实操建议：
- 绝不裸写
$pdo->beginTransaction()，必须包裹在 try/catch 中且确保 finally 有回滚兜底 - 避免在事务块内调用可能抛异常但未声明的第三方函数（如文件读写、HTTP 请求）
- 事务内不要做耗时操作（如大文件处理、sleep），否则锁表时间过长
用外观模式封装事务：核心是 TransactionFacade 类
外观模式在这里不是为了“解耦”，而是把事务的开启、提交、回滚、异常恢复、嵌套控制收束到一个干净接口里，让业务代码只关心 begin()、commit()、rollback() —— 其他细节由外观内部消化。
立即学习“PHP免费学习笔记（深入）”；
关键设计点：
- 持有一个
PDO实例和一个$depth计数器，支持嵌套调用（begin()多次只真正开启一次事务） -
commit()只在最外层调用时真正提交，内层调用仅递减计数器 -
rollback()无论哪层调用，都强制回滚并重置计数器（嵌套中出错必须全部撤回） - 构造函数接收
$pdo和可选的$autoRollbackOnDestruct = true，防止对象被销毁但事务悬空
示例最小实现：
class TransactionFacade
{
private PDO $pdo;
private int $depth = 0;
private bool $autoRollbackOnDestruct;
public function __construct(PDO $pdo, bool $autoRollbackOnDestruct = true)
{
$this->pdo = $pdo;
$this->autoRollbackOnDestruct = $autoRollbackOnDestruct;
}
public function begin(): void
{
if ($this->depth === 0) {
$this->pdo->beginTransaction();
}
$this->depth++;
}
public function commit(): void
{
if ($this->depth > 0) {
$this->depth--;
if ($this->depth === 0) {
$this->pdo->commit();
}
}
}
public function rollback(): void
{
if ($this->depth > 0) {
$this->depth = 0;
$this->pdo->rollback();
}
}
public function __destruct()
{
if ($this->autoRollbackOnDestruct && $this->depth > 0) {
$this->rollback();
}
}
}
实际使用时怎么避免“假成功”陷阱
很多开发者以为调用了 $facade->commit() 就万事大吉，但 PDO 的 commit() 成功只代表指令发出去了，不保证数据库已落盘（尤其在 autocommit 关闭 + 事务隔离级别为 READ COMMITTED 时）。更危险的是：网络闪断后 commit() 抛异常，但业务逻辑误判为“已提交”。
实操建议：
- 所有
commit()调用必须检查返回值或捕获PDOException，不能静默忽略 - 关键业务（如支付扣款）建议在
commit()后立刻执行一条轻量SELECT验证数据状态，例如$pdo->query("SELECT balance FROM accounts WHERE id = 123")->fetch() - 不要依赖
__destruct()做最终保障——PHP 垃圾回收时机不可控，应显式调用rollback()在 catch 块中 - 若使用连接池或长连接，注意
PDO实例复用时事务状态残留，每次新请求需确认$pdo->inTransaction() === false
与 Laravel DB::transaction() 的关键区别在哪
Laravel 的 DB::transaction() 是函数式接口，传入闭包自动管理生命周期；而手动封装的 TransactionFacade 是面向对象、显式控制流。这不是优劣问题，而是适用场景不同：前者适合快速 CRUD 场景，后者适合需要跨多个 Service 类协作、或需细粒度控制（如部分回滚、保存点）的复杂流程。
比如你要在订单创建事务中，先插入订单，再调用库存服务扣减，再发消息——用闭包会把三者耦合在一个函数里；而用外观模式，可以这样写：
$facade->begin();
try {
$orderService->create($data);
$inventoryService->decrease($sku, $qty);
$messageService->send('order.created', $order);
$facade->commit();
} catch (Throwable $e) {
$facade->rollback();
throw $e;
}
这里每个 Service 内部完全不知道事务存在，也不用传 $facade，它们只负责自己的逻辑，事务边界由外观统一划清。
真正容易被忽略的是：外观模式封装后，开发者容易忘记事务的“连接绑定”本质——同一个 TransactionFacade 实例必须贯穿整个业务流程，不能在不同函数中 new 多个实例去操作同一张表，否则事务隔离失效。
