thinkphp读写分离失效主因是deploy和rw_separate开关位置或类型错误：二者必须同在connections['mysql']内，deploy=>1启用分布式，rw_separate=>true（布尔型）开启自动分流，缺一不可。
ThinkPHP数据库读写分离配置失效，90% 是因为关键开关没写对位置或类型不对，而不是从库连不上或 SQL 写错了。核心要确认三件事：开关是否启用、结构是否合规、运行时是否满足分流条件。
检查 deploy 和 rw_separate 是否同时存在且位置正确
这两个键必须同时出现在 config/database.php 的 connections['mysql'] 数组内部，缺一不可，也不能写在外层或 default 里：
- 'deploy' => 1：分布式模式总开关，漏掉则整个读写分离逻辑不初始化
- 'rw_separate' => true（必须是布尔 true，不是字符串 'true'）：读写自动分发开关，若从 .env 读取，需用 filter_var 转换
- 常见错误：把它们写在 connections 外、default 下、或注释掉其中一个；TP6/8 只扫描具体连接块，不继承全局配置
验证 read/write 数组结构是否符合框架硬性要求
TP6 对数组维度极其敏感，格式错一点就报 Call to a member function query() on null 或启动失败：
-
read 必须是二维数组：哪怕只有一个从库，也要写成
[ ['hostname' => '192.168.1.11', 'database' => 'myapp'] ]，不能是['hostname' => '...'] -
write 必须是单维完整数组：只允许一个主库配置，不能是
[ [...] ]或多个元素，否则抛出 Invalid write database config - 所有节点（主+从）的 database 名必须完全一致，否则事务或 JOIN 会出错；从库缺 username/password 会静默失败，查 runtime/log 可见提示
确认当前操作是否真的触发读路由
TP6 不是“所有 SELECT 都走从库”，而是按方法语义和上下文判断：
- 只有
select()、find()、value()、column()等纯读方法才可能走 read；insert()、update()、save()强制走 write - 事务中一律走主库：startTrans() 后所有操作（包括 select）都回落 write，这是设计行为，不是 bug
- 连贯操作含
lock(true)、order()+limit()+count()组合时可能被误判为写意图，建议显式加->useReadConnection() - 手动调用
Db::connect('xxx')创建的独立连接，不参与全局读写分离逻辑
查看日志与运行时状态辅助定位
别只看接口返回，要盯住底层行为：
- 打开
APP_DEBUG = true，查runtime/log/最新日志，搜索 Database config 或 query on null 等关键词 - 在控制器中临时加
dump(config('database.connections.mysql'));，确认 read/write 结构是否如你所写 - 执行
Db::table('user')->useReadConnection()->getLastSql()，看生成的 SQL 是否真由从库执行（配合 MySQL 的 general_log 或慢日志验证） - 若用 Redis 缓存，记得清空
runtime/cache/，否则旧 schema 缓存可能导致配置不生效
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
