Hyperf 3.0 不支持 rw_splitting 参数，读写分离需显式配置 read/write 数组，sticky=true 防主从延迟，连接池与负载策略需手动调优，且依赖主从复制稳定性及权限配置。
rw_splitting 参数在 Hyperf 3.0 中并不存在——Hyperf 官方数据库组件（hyperf/db-connection）从 2.x 到 3.0 均未提供名为 rw_splitting 的配置项，也无对应开关或中间件自动启用该功能。读写分离完全依赖 read/write 连接数组 + 路由策略实现，不是靠一个布尔参数“打开”就能生效的。
Hyperf 3.0 的 read/write 配置结构必须显式声明
Hyperf 不会自动探测 SQL 类型再决定走哪条连接；它只在构建查询时，根据当前连接解析器返回的连接实例来路由。因此你必须在 config/autoload/databases.php 中明确写出 read 和 write 数组：
-
read是一个数组，每个元素是一个完整数据库配置（支持多从库），不能只写host字段，username、password、port等需独立配置（尤其从库应使用只读账号） -
write同样是数组，但生产环境通常只配一个主库地址；若配多个，Hyperf 默认取第一个，不自动 failover - 遗漏
read或write中任意一项，会导致对应操作报Connection not found错误，而不是降级到默认连接
sticky=true 是防止主从延迟读不到数据的关键开关
当一次请求中先执行了写操作（如 save() 或 Db::insert()），紧接着又做读操作（如 find()），若不开启 sticky，Hyperf 可能将后续读路由到从库，而此时从库还没同步完，导致查不到刚写入的数据。
-
sticky => true会让本次请求生命周期内所有读操作复用刚用过的写连接（即主库），直到请求结束 - 该行为仅对当前协程/请求有效，不影响其他并发请求
- 若业务允许短暂延迟（如商品详情页刷新不强求秒级一致），可设为
false以提升从库利用率 - 注意：事务内所有语句（含
SELECT）强制走write连接，sticky对其无效
从库连接池和负载策略需手动调优
Hyperf 默认对 read 和 write 使用同一套连接池配置，但实际中从库更需要高并发承载能力，主库则更关注写入稳定性。
- 必须为
read单独配置pool参数（如max_connections => 50），否则所有读请求挤在默认的 20 连接里，反而比单库还慢 - 负载策略由
Hyperf\Database\ConnectionResolver决定，默认轮询（RoundRobin），不支持权重或健康检查；若某从库响应慢，它仍会被均分流量 - 没有内置机制自动剔除宕机从库——需自行实现
Connection的 ping-on-borrow 或结合外部服务发现（如 Nacos）动态更新配置 - 别把
read地址写成127.0.0.1：本地测试没问题，上线后网络延迟、DNS 解析失败等问题会直接暴露
真正难的从来不是配几个数组，而是主从复制是否真通、Seconds_Behind_Master 是否稳定、从库账号是否有足够权限、以及业务代码里有没有绕过 Eloquent / DB 门面直接 new PDO——这些地方一漏，read/write 配得再漂亮也白搭。
