thinkphp 6/8 读写分离必须同时满足 deploy=1、rw_separate=true、read/write 结构正确三要素，且全部置于 connections['mysql'] 内；tp5 则依赖 read_master 与非事务上下文，逻辑完全不同。
ThinkPHP 6/8 的读写分离不是“配了从库地址就自动分流”，必须同时满足 deploy=1、rw_separate=true、read 和 write 结构正确这三要素，且全部写在 connections['mysql'] 内部；TP5 则依赖 read_master + 非事务上下文，逻辑完全不同，混用会彻底失效。
TP6/8 读写分离根本没触发：开关位置或缺失
TP6/8 不会因配置了多个数据库地址就初始化读写分离逻辑。它只认 connections['mysql'] 内部的两个布尔开关：
-
deploy => 1是分布式模式总开关，漏掉则整个路由机制不加载 -
rw_separate => true是读写自动分发开关，设为false或字符串'true'（未用filter_var转换）都会导致所有查询走主库 - 常见错误：把它们写在
default下、connections外层、或只写一个而注释掉另一个 - TP8 中若从
.env读取，必须写成：'rw_separate' => filter_var(Env::get('DB_RW_SEPARATE', 'false'), FILTER_VALIDATE_BOOLEAN)，否则恒为false
TP6/8 报错 Call to a member function query() on null：read/write 结构错误
这个报错几乎 100% 源于 read 或 write 数组格式不符合框架硬性要求：
-
read必须是二维数组，哪怕只有一个从库也要写成[ ['hostname' => '192.168.1.11', 'database' => 'myapp'] ]；写成一维['hostname' => '...']会导致连接对象为null -
write只能是单个完整配置数组，不能是数组套数组，否则启动直接抛出Invalid write database config - 所有节点（主+从）的
database名必须完全一致，否则跨库 JOIN 或事务会失败 - 从库配置中若缺
username或password，可能静默失败，需查runtime/log中的Database config write is invalid
TP5 为什么设了 read_master 却没走从库？
TP5.0–5.1 的从库路由极简，只依赖两个运行时条件，和配置是否“看起来完整”无关：
- 当前不在事务中（
inTransaction()返回false） - 上一条执行的 SQL 不是写操作（即非
INSERT/UPDATE/DELETE），靠内部lastSql标记判断 - 常见踩坑：
insert()后立刻select()，哪怕加了slave()方法也无效，因为写标记仍在 -
slave配置必须是一维扁平结构：'hostname' => 's1,s2'、'username' => 'u1,u2'，不能写成二维数组，否则静默失败 -
deploy => 1是前提，缺了它read_master和rw_separate全部被忽略
事务中 select() 还是走主库，或报 There is no active transaction
TP6/8 在事务中强制关闭读写分离，所有语句（包括 select()）都走主库——这是设计行为，不是 bug。但旧版或定制分支可能出现连接池不同步问题：
- 标准 TP6.3+ 中，
startTrans()会同步初始化主库与所有从库连接，commit()才不会报There is no active transaction - 若使用非官方分支，需检查
think\db\Connection::startTrans()是否对全部连接调用了beginTransaction() - 临时规避：事务内避免纯查询；或显式用
Db::master()->select()强调主库意图 - TP5 中事务内所有操作（含
find()）强制走主库，且不支持从库参与事务
最易被忽略的是：TP6/8 的 read 配置必须是非空二维数组，哪怕灰度阶段只启用一个从库，也不能留空或降级为一维；TP5 的 slave 地址必须用逗号拼接，且 deploy=1 缺一不可——这些不是可选建议，而是框架解析时的硬校验点。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
