WordPress 无内置事务，CI4 虽支持但与 WP 混用易引发锁冲突；根源在于锁粒度错位、隔离级别混用及事务边界模糊；应统一访问顺序、禁用全表扫描、瘦身事务并复用 $wpdb 显式控制。
WordPress 本身不内置事务管理，它的数据库操作默认是自动提交的；而 CodeIgniter 4（CI4）提供了完整的事务支持，但直接套用在 WP 环境中容易因锁机制不匹配引发并发冲突——尤其当 CI4 的事务与 WordPress 插件、主题或 REST API 中隐式执行的 SQL 交叉时，InnoDB 行锁/间隙锁可能意外升级、范围扩大，甚至触发死锁。
WP+CI4混合架构下的锁冲突根源
不是“事务用了就安全”，而是“事务怎么用才不打架”。关键问题在于：
-
锁粒度错位：CI4 手动开启事务后执行
UPDATE，若 WHERE 条件未命中索引，InnoDB 会退化为全表扫描+表级锁，而 WP 后台定时任务（如 wp-cron）、插件日志写入、用户登录态更新等仍在并发执行，瞬间阻塞。 -
隔离级别混用：CI4 默认使用
READ_COMMITTED，但 WP 核心及多数插件（如 WooCommerce）依赖REPEATABLE_READ保证一致性；混合事务下，间隙锁行为不一致，极易在范围查询（如分页列表）中形成循环等待。 -
事务边界模糊：CI4 的
$db->transStart()和$db->transComplete()若嵌套在 WP 的钩子（如save_post）里，可能被 WP 自身的 DB 操作打断，导致锁未释放就返回，留下长事务隐患。
重构建议：轻量、有序、索引驱动
不推翻现有架构，只做三处关键收敛：
-
统一资源访问顺序：所有涉及多表更新的操作（如订单+库存+日志），强制按主键 ID 升序排列后再批量处理。例如先锁
posts.ID=100，再锁postmeta.post_id=100，避免 A 锁 meta 再等 post、B 锁 post 再等 meta 的死锁环路。 -
禁用隐式全表扫描：对 CI4 中所有
WHERE字段，检查对应 MySQL 列是否建有索引。特别注意wp_posts.post_status、wp_postmeta.meta_key这类高频过滤字段——没索引就加，宁可冗余也不留隐患。 - 事务瘦身 + 显式释放：把 CI4 事务控制在最小必要范围。例如“创建订单”逻辑中，仅包裹库存扣减和订单写入两步，支付回调确认、邮件发送、统计更新等全部移出事务块，改用异步队列或 WP cron 延后执行。
CI4 配合 WP 的安全事务模板
以下是一个防冲突的典型写法（非伪代码，可直接落地）：
// 使用 WP 原生 $wpdb 保持上下文一致，而非 CI4 的独立连接
global $wpdb;
$wpdb->query('START TRANSACTION');
<p>try {
// 1. 先查再锁：用 FOR UPDATE 显式声明意图，且必须走索引
$order = $wpdb->get_row($wpdb->prepare(
"SELECT id, stock FROM wp_products WHERE sku = %s FOR UPDATE",
$sku
));</p><pre class="brush:php;toolbar:false;">if (!$order || $order->stock < $quantity) {
throw new Exception('库存不足');
}
// 2. 更新库存（行锁已持住，安全）
$wpdb->update('wp_products', ['stock' => $order->stock - $quantity], ['sku' => $sku]);
// 3. 写订单（同样走主键或唯一索引）
$order_id = $wpdb->insert('wp_orders', [
'user_id' => get_current_user_id(),
'status' => 'pending',
'created' => current_time('mysql')
]);
$wpdb->query('COMMIT');} catch (Exception $e) { $wpdb->query('ROLLBACK'); error_log('Order transaction failed: ' . $e->getMessage()); }
要点：复用 $wpdb 连接，避免双连接引发锁竞争；FOR UPDATE 必须配合索引字段；异常路径确保回滚，不遗留悬挂锁。
不复杂但容易忽略：WP 场景下，事务不是越多越好，而是越准越好——锁住该锁的，放开不该锁的，顺序清晰，索引到位，就能避开 90% 的并发卡顿。
