ThinkPHP批量插入失败首要排查字段缓存未更新导致新增字段被忽略；其次检查数据合规性、分批控制、事务兜底及外部限流等全链路问题。
ThinkPHP批量插入失败，往往不是语法写错这么简单，而是多个环节耦合出的问题。关键得顺着数据从PHP到数据库的路径，一层层检查。
先看是不是字段缓存没更新
模型字段结构改了，但 runtime/Data/_files 下的字段缓存还是旧的，新增字段直接被忽略——这是最隐蔽也最常见的“插入成功但数据丢字段”现象。尤其用 M()->add() 或 saveAll() 时容易中招。
- 清空 Runtime/Data/_files 和 Runtime/Cache 目录
- 在配置文件（如 debug.php）中显式关闭字段缓存：
'DB_FIELDS_CACHE' => false - 开发阶段建议始终关掉模板和字段缓存，上线再按需开启
再查数据本身是否合规
批量插入对数据一致性要求更高，单条能过、批量就挂，大概率是某条数据踩了雷。
- 检查每条记录是否都包含非空必填字段（尤其是设置了 NOT NULL + DEFAULT NULL 的字段）
- 确认所有字段值类型匹配：整数传了字符串、时间字段传了空字符串、文本超长截断等
- 验证唯一索引字段（如 email、code）是否重复——insertAll() 不自动跳过重复项，会直接报错中断
- 用 Db::getLastSql() 打印生成的 SQL，复制到 phpMyAdmin 或 MySQL CLI 中手动执行，看具体报什么错
分批与内存控制必须到位
一次塞几千条，不拆分、不清理、不设限，PHP 进程很容易崩在半路，还找不到日志。
立即学习“PHP免费学习笔记（深入）”；
- 每批控制在 200–500 条，用 array_chunk($data, 400) 拆分
- CLI 脚本开头加 set_time_limit(0)，避免超时中断
- 每批执行后调用 gc_collect_cycles()，防止内存持续上涨
- Web 请求场景下，别硬扛大批次——改用队列（如 think-queue）异步处理
事务和异常必须兜底
批量写入默认是非事务的，一旦中间某条失败，前面成功的数据就留在库中，形成脏数据。
- 务必用 Db::transaction() 包裹整个批量逻辑
- 不要混用 saveAll() 和 Db::insertAll()，它们底层可能走不同连接，事务失效
- 捕获异常并记录完整错误信息，例如：
try { ... } catch (\Exception $e) { \think\facade\Log::error('批量插入失败: ' . $e->getMessage()); }
最后确认环境与权限
有些问题藏在框架之外。
- 检查数据库用户是否有 INSERT 权限（特别是多表或分区表场景）
- 确认 MySQL 的 max_allowed_packet 是否足够（大批量时可能超限）
- Web 环境下注意 Nginx/Apache 的超时设置（如 fastcgi_read_timeout），别让网关先断开
- 如果数据来自外部 API，要排查是否触发了对方的限流（HTTP 429），导致部分请求返回空或非法响应，进而生成错误 SQL
