ThinkPHP5.0锁机制失效主因是lock(true)未在事务内调用、WHERE条件未走索引致锁升级、事务未正确提交或回滚、乐观锁版本校验缺失、持久连接或读写分离干扰锁执行。
ThinkPHP5.0中数据库锁机制失效、出现并发写入冲突，核心原因往往不是“锁没加”，而是锁没生效或没用对地方。排查要从锁是否真正落地、事务是否完整可控、底层行为是否符合预期三个层面切入。
一、确认lock(true)是否真起了行锁作用
很多人写了->lock(true)就以为万事大吉，但实际可能完全没生效：
- 检查该查询是否在
Db::startTrans()之后调用——不在事务内，lock(true)会静默失效，MySQL根本不执行SELECT FOR UPDATE； - 用
SHOW ENGINE INNODB STATUS\G查“TRANSACTIONS”部分，看当前活跃事务里是否有SELECT ... FOR UPDATE语句及对应行锁记录； - 确认WHERE条件是否走索引——没索引时InnoDB会升级为表锁或锁住更大范围（如间隙锁），反而加剧冲突，可用
EXPLAIN验证执行计划； - 避免在模型查询中混用
find()和select()：只有find()类单行查询配合lock(true)才触发行锁，select()默认不支持。
二、检查事务生命周期是否被意外中断或复用
事务没正确提交或回滚，会导致锁长期持有甚至连接泄漏，后续请求看似“没锁”实则卡在等待队列：
- 所有
lock(true)查询必须包裹在Db::startTrans()与Db::commit()/Db::rollback()之间，中间不能有return、异常未捕获、或exit/die； - 禁用调试模式（
app_debug = false），否则Trace日志写入可能阻塞事务完成； - 检查是否有中间件或钩子在事务中途强制
Db::close()或切换了连接实例，导致锁上下文丢失； - 用
SHOW PROCESSLIST观察是否存在State: Locked或长时间Sleep状态的连接，对应排查代码中是否遗漏commit或rollback。
三、排除乐观锁误用或版本字段未校验
若用了乐观锁（如version字段），冲突不会报死锁，而是静默覆盖或更新失败，容易误判为“没加锁”：
立即学习“PHP免费学习笔记（深入）”；
- 确认更新SQL中是否包含
WHERE version = ?条件，且更新后version自增——TP5需手动在save()时传入['version' => $oldVersion + 1]； - 检查是否在事务外执行乐观锁校验：乐观锁本身不依赖事务，但若校验与更新分两次查询，中间仍可能被其他请求插入；
- 日志中搜索
affected_rows = 0，这是乐观锁失效的典型信号，说明版本号不匹配导致更新未执行。
四、验证底层连接与配置是否干扰锁行为
某些配置会让锁机制“看起来失效”：
- 数据库配置中
'persistent' => true（持久连接）可能导致连接复用时事务状态残留，建议设为false； -
'deploy' => 1（读写分离）下，lock(true)若发到从库则无效，确保写操作明确走主库（如Db::connect('master')->name(...)->lock(true)）； - 隔离级别为
READ-COMMITTED时，间隙锁被禁用，但幻读风险上升；若业务依赖间隙锁防并发插入，需确认是否误调低了隔离级别。
