ThinkPHP 6/8 原生支持读写分离，无需第三方类库；其基于方法语义自动路由（读走从库、写走主库），事务与锁查询强制主库，配置错误是失效主因。
ThinkPHP 本身已内置读写分离能力，无需整合第三方类库来实现主从路由。强行引入外部库（如自定义连接池、中间件代理或独立 DB 路由器）不仅增加复杂度，还容易与框架原生机制冲突，导致连接错乱、事务失效或配置不生效。
为什么不需要第三方类库
ThinkPHP 6/8 的读写分离是框架级特性，基于连接配置自动识别读/写语义：
- select()、find()、value()、column() 等纯读方法默认走从库（满足条件时）
- insert()、update()、delete()、save() 等写操作强制走主库
- 事务中、带锁查询（lock(true)）、FOR UPDATE 语句一律回落主库，保障一致性
- 所有路由逻辑由 Db 类内部完成，不依赖外部类或运行时拦截
常见误用：试图用第三方方式“增强”读写分离
以下做法实际无效或有害：
- 写一个“DBRouter”类，在控制器里手动判断 SQL 类型再选库——TP 已做更精准的语义分析，且无法覆盖模型层行为
- 用 Composer 安装某“MySQL-Balance”包，替换 PDO 连接——会绕过 TP 的连接管理，导致事务、日志、缓存等功能异常
- 在中间件里调用 Db::setConnectConfig() 动态改 read 数组——配置变更不会实时生效，且可能污染连接池
- 用 Swoole Process 启动独立读库监听进程——TP 不支持跨进程共享连接状态，极易出现连接泄漏或认证失败
真正需要扩展的场景，应优先用 TP 原生机制
若需定制行为，推荐使用框架预留的扩展点：
立即学习“PHP免费学习笔记（深入）”；
-
轮询策略调整：重写
getReadConnection()方法，按用户 ID 或请求路径哈希选择从库 - 故障转移：在 Db::event('before_select') 中捕获 PDOException，自动切换下一个从库并重试
-
灰度控制：通过 .env 配置开关，配合
filter_var(Env::get('DB_RW_SEPARATE'), FILTER_VALIDATE_BOOLEAN)动态启用 - 延迟感知：在从库配置中加入 ping 检测逻辑（需继承 Connection 类），但注意避免每次查询都连通检测
配置出问题？先检查这三处
90% 的“读写分离不生效”不是功能缺失，而是配置未到位：
-
开关位置错误：deploy 和 rw_separate 必须写在
connections['mysql']内部，写在 default 或顶层 config 下完全无效 -
数组结构错误：read 必须是二维数组（哪怕只有一个从库也要写成
[['hostname' => '...']]），write 必须是单数组 - database 名不一致：主库和所有从库的 database 参数必须完全相同，否则 JOIN 或跨表操作失败
