php不检测死锁，mysql innodb主动发现并回滚事务；php需捕获错误码1213、定位代码、重试幂等操作，配合innodb_print_all_deadlocks=on记录全量死锁日志。
PHP 本身不检测死锁，死锁由 MySQL InnoDB 引擎主动发现并回滚其中一个事务；PHP 要做的，是捕获错误、定位源头、配合重试——而不是“自己去检测”。
如何确认报错确实是死锁（不是锁等待）
关键区别在错误码和语义：
-
1213（Deadlock found when trying to get lock）：真死锁，InnoDB 已选一个事务回滚，当前语句失败，需重试整个事务 -
1205（Lock wait timeout exceeded）：只是锁等待超时（默认innodb_lock_wait_timeout = 50），对方事务还没结束，但你等不及了——这不是死锁，重试未必有效，应先查长事务
别把 SHOW PROCESSLIST 里看到的 Locked 状态当成死锁；也别把慢查询日志里的耗时高直接归因为死锁。死锁一定伴随明确的 1213 错误抛出。
怎样从 PHP 日志快速定位触发死锁的代码位置
光有 PDOException 不够，必须让异常带上上下文：
- 在事务开始前打点：
error_log("[TX] update_order_status, uid={$uid}, order_id={$oid}"); - 用
try/catch包住DB::transaction()或原生$pdo->beginTransaction()，并在catch中记录完整堆栈 +$e->getCode()+$e->getMessage() - ThinkPHP 用户注意：
Db::transaction()默认不透出 SQL，需手动开启log_sql并确保日志包含请求 ID（如X-Request-ID）
否则你只会在日志里看到一行 SQLSTATE[40001]: Serialization failure: 1213 Deadlock found...，完全不知道是哪个用户、哪个接口、哪条 SQL 撞上的。
为什么不能靠定时轮询 SHOW ENGINE INNODB STATUS\G 来“检测”死锁
这个命令返回的是最后一次死锁信息，且每次执行都会被新死锁覆盖——它不是监控接口，而是诊断快照：
- 脚本轮询容易漏掉瞬间发生的死锁（尤其线上低频但关键场景）
- 解析输出不稳定：
LATEST DETECTED DEADLOCK块格式可能随 MySQL 版本微调，正则易失效 - 真正可靠的方式是开
innodb_print_all_deadlocks = ON，让 MySQL 自动把每次死锁写进error_log（路径查SHOW VARIABLES LIKE 'log_error'）
这个配置几乎零性能损耗，只在真实死锁发生时落盘，比任何 PHP 层轮询都准、都轻量。
PHP 层该不该封装“死锁重试逻辑”
应该，但必须加限制：
- 只对幂等操作重试：比如
UPDATE stock SET qty = qty - 1 WHERE id = ? AND qty >= 1，重试安全；但INSERT INTO log (msg)或file_put_contents()绝对不能重试 - 重试次数严格控制在 2～3 次，用指数退避（如 100ms → 300ms → 900ms），避免雪崩
- Laravel 8+ 可直接用
DB::transaction($callback, $attempts = 3)；原生 PDO 需手写带catch (PDOException $e) { if ($e->getCode() == 1213) { ... } }的循环
最常被忽略的一点：重试前必须重新生成业务数据（比如重新查库存、重取订单状态），不能拿旧变量硬塞进第二次事务——否则可能因状态已变导致逻辑错乱。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
