ci4读写分离下insert_id()返回0或错误值，根本原因是写操作走主库连接，但insert_id()可能从刚切换的从库连接取值；必须紧接insert()后在同一连接实例调用，且事务失败后该id仍有效，需业务层主动判废。
CI4读写分离下insert_id()返回0或错误值
在CodeIgniter 4开启读写分离后，insert_id()经常返回0或null，不是驱动bug，而是连接路由机制导致的：写操作走主库连接，但insert_id()默认从当前活动连接（可能是刚切过去的从库连接）取值。CI4的$db->insertID()或$db->insert_id()必须紧接在insert()之后、且在同一数据库连接实例上调用，否则失效。
- 确保插入后**立刻调用**
insert_id()，中间不能穿插任何其他查询（尤其是select），否则连接可能被池管理器回收或切换 - 不要在事务外跨多个
$db实例调用——CI4读写分离会为读/写分别创建连接池，insert()用的是写连接，但若后续误用$this->db（未显式指定组）可能拿到读连接 - 推荐显式使用写组连接：
$writedb = \Config\Database::connect('writable');，然后统一用$writedb->table()->insert()+$writedb->insertID()
事务中insert_id()在rollback()后仍有效
MySQL的LAST_INSERT_ID()是连接级变量，不受事务回滚影响。即使你执行了$db->transRollback()，之前insert()生成的ID仍保留在该连接上，下次调用insert_id()会返回旧值而非0。这容易造成逻辑错乱，比如误认为新记录已插入成功。
- 事务失败后，手动重置连接上的ID值不可行（MySQL无
RESET LAST_INSERT_ID语句），唯一可靠方式是**重建连接**或**显式忽略该ID** - 业务层需在
transComplete()为false时，把刚获取的insert_id()视为无效，不参与后续逻辑 - 避免在事务内依赖
insert_id()做关联插入（如先插用户再插订单），改用INSERT ... SELECT或应用层缓存ID
insert_id()与mysqli_insert_id()底层行为差异
CI4的insert_id()最终调用的是PDO的lastInsertId()或MySQLi的mysqli_insert_id()，但两者对“最后插入”的定义不同：PDO要求明确指定序列名（PostgreSQL）或忽略参数（MySQL），而MySQLi的mysqli_insert_id()只认当前连接最后一次INSERT。CI4封装层没做适配，直接透传，导致跨驱动行为不一致。
- MySQLi驱动下，只要连接没断，
insert_id()始终返回最近一次INSERT的ID，哪怕中间执行了UPDATE或DELETE - PDO驱动下，若表主键非自增或使用
UUID，lastInsertId()可能返回空字符串或0，CI4不会报错也不会fallback - 检查当前驱动：
var_dump($db->getPlatform());，MySQLi返回mysql，PDO返回pdo，据此决定是否加兜底判断
主从延迟导致insert_id()被误用于从库查询
开发常犯的错误是：拿到insert_id()后，立刻用select()查这条记录，却没意识到CI4读写分离默认把select发到从库——而主从同步有延迟，刚插入的记录可能还没复制过去，查不到结果。
- 严格要求“写后即读”场景，必须强制走主库：
$db->groupStart()->where('id', $id)->from('users')->useMaster()->get() - 不要依赖
insert_id()做条件查询，改用业务唯一标识（如订单号、token）替代ID作为关联字段 - 监控主从延迟：
SHOW SLAVE STATUS\G中的Seconds_Behind_Master，超过1秒就应规避强一致性读
insert_id()和连接生命周期绑定这一事实——它不随事务状态变化，也不受读写组切换自动刷新，所有“取完ID就放心用”的假设，在读写分离+事务混合场景下都可能翻车。
