ci4原生不支持读写分离，需手动配置write和read两个独立数据库组，api中按操作类型显式创建对应实例，写操作必须用write连接并控制事务，读操作优先read但强一致性场景须回退write。
CodeIgniter 4（CI4）原生不支持数据库读写分离，必须手动实现；直接复用 CI4 的 $db 单例或依赖注入默认连接，会导致所有查询都打到同一库，读写分离形同虚设。
CI4 中如何配置主从数据库连接
CI4 的 Database 类设计为单连接实例，默认只加载一个组（如 default）。要支持读写分离，需显式创建两个独立的数据库实例，并避免共享连接池或配置缓存。
- 在
app/Config/Database.php中定义两个独立组：一个叫write（主库），一个叫read（从库），确保它们的DNS、username、password、port完全独立 - 禁用
DB_DEBUG或谨慎开启——调试模式下 CI4 会强制重连并忽略连接复用，加剧主库压力 - 不要在
Database.php中设置shared或reuse相关参数，CI4 不支持跨组连接复用，强行启用反而引发事务异常
在 API 控制器中动态选择读/写连接
不能依赖 $this->db 默认实例，必须每次按操作类型显式获取对应连接。CI4 没有类似 FastAPI 的依赖注入机制，需手动 new 实例或封装工厂函数。
- 写操作（INSERT/UPDATE/DELETE）必须使用
new Database('write')创建的新实例，且务必调用transStart()+transComplete()显式控制事务 - 读操作（SELECT）应使用
new Database('read')，但要注意：若该查询需强一致性（例如刚写完立刻查），必须回退到write连接，否则可能因复制延迟返回旧数据 - 避免在模型（Model）中硬编码
$this->db—— 模型应接收连接实例作为构造参数，或通过服务容器注入，否则无法灵活切换
复制延迟导致 API 返回脏数据怎么办
CI4 本身无延迟感知能力，复制延迟问题只能靠业务层兜底，不是配个从库就能自动解决。
- 对“写后即读”场景（如用户注册后跳转个人页），强制走
write连接，哪怕只是 SELECT；可加标识字段（如read_preference=strong）在请求头或参数中传递 - 不要依赖 MySQL 的
WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS——CI4 的 Query Builder 不暴露底层复制状态接口，且该函数仅适用于 GTID 模式，生产环境兼容性差 - 若必须读从库但又要规避延迟，可在从库执行
SELECT MASTER_POS_WAIT(...)手动等待同步点，但会显著拖慢响应时间，仅限关键路径慎用
真正难的不是配两个数据库链接，而是让每个 API 路径明确知道自己该读哪个库、什么时候该放弃从库。复制延迟不是配置问题，是架构取舍——你得在性能和一致性之间划那条线，CI4 不替你做决定。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
