PDO::lastInsertId() 更可靠，因其明确绑定当前 PDO 实例，避免连接池或长连接复用导致的 ID 错乱，且在事务中准确反映本事务最后一次插入的 ID。
在 PHP 中新增数据后获取自增 ID，mysqli_insert_id() 和 PDO::lastInsertId() 都能用，但行为差异明显。关键不是“哪个更快”，而是“是否在同一个连接上下文里执行”。如果用了连接池、长连接复用或中间件（比如某些 Swoole 框架），mysqli_insert_id() 可能返回上一个请求的 ID —— 因为它依赖 MySQL 连接句柄的内部状态，且不接受参数。
而 PDO::lastInsertId() 在调用时明确绑定到当前 PDO 实例，只要没换对象、没重连，就安全。尤其在事务中，它只反映本事务内最后一次 INSERT 的 ID。
mysqli_insert_id($link) 推荐显式传入连接资源，避免全局隐式连接干扰PDO::lastInsertId() 不带参数即可，但注意：若手动指定了序列名（如 PostgreSQL），需传参；MySQL 下忽略参数SELECT MAX(id) 替代——并发插入时大概率错最常见原因是：执行 INSERT 语句失败了，但没检查返回值。哪怕 SQL 语法正确，也可能因唯一键冲突、字段超长、外键约束等导致插入失败，此时 mysqli_insert_id() 必然返回 0 —— 它只对真正成功插入的语句有效。
另一个隐蔽原因是：使用了 INSERT ... ON DUPLICATE KEY UPDATE。这种语句在发生重复时实际是“更新”而非“插入”，MySQL 不会分配新 ID，所以 mysqli_insert_id() 返回 0 或原 ID（取决于是否触发 AUTO_INCREMENT 更新）。
mysqli_query() 返回值是否为 true
ON DUPLICATE KEY UPDATE 场景，改用 INSERT ... SELECT LAST_INSERT_ID(...) 或分两步处理mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT) 让错误直接抛异常，避免静默失败必须在 INSERT 之后、COMMIT 之前调用。虽然 MySQL 允许事务未提交就读取刚插入的 ID，但一旦 ROLLBACK，这个 ID 就作废了 —— 而且后续插入仍会继续递增，造成 ID 空洞。这不是 bug，是 InnoDB 的正常行为。
更危险的是：有人把 lastInsertId() 放在 COMMIT 之后，以为“更稳妥”。实际上，如果 COMMIT 失败（比如锁等待超时），那这行代码根本不会执行；而如果 COMMIT 成功，再调用也已脱离事务上下文，可能被其他连接干扰（极小概率，但存在）。
$pdo->beginTransaction();
$pdo->exec("INSERT INTO users (name) VALUES ('Alice')");
$user_id = $pdo->lastInsertId(); // 立即获取
$pdo->exec("INSERT INTO profiles (user_id, bio) VALUES ($user_id, '...')");
$pdo->commit();
SQL —— SQL 注入风险陡增，应改用预处理MySQL 8.0.19+ 支持 INSERT ... RETURNING id 语法，看起来比两次交互更高效。但它在 PHP 中不能直接用 mysqli 或 PDO 获取结果集 —— 因为该语句返回的是结果集（Result Set），不是影响行数，而 lastInsertId() 机制只识别自增列变更。
你得用 mysqli_query() 执行后，再调用 mysqli_fetch_row() 提取，相当于手动模拟。好处是能一次拿到多个列（比如 UUID + 时间戳），坏处是丧失了 lastInsertId() 对连接状态的自动管理能力。
RETURNING，请确保驱动版本足够新（mysqli >= 8.0.19，PDO MySQL >= 8.0.19）PDO::FETCH_ASSOC 可直接映射字段，但要注意：返回的是结果集，不是自增 ID 缓存值lastInsertId() —— 它更轻量、更兼容、更不容易出错