报 max_allowed_packet 错误需分片插入而非调大配置，推荐每批200–500条，用array_chunk切分、Db::insertAll批量执行并事务控制，避免saveAll，注意索引连续性、关闭调试与日志，大数据字段需进一步减量。
报 max_allowed_packet 错误，本质是 MySQL 拒绝接收过长的 SQL 包，而 ThinkPHP 批量插入（如 insertAll）会把所有数据拼成一条 INSERT INTO ... VALUES (),(),()... 语句——数据一多，SQL 就超限。这不是 TP 的 bug，而是必须正视的底层约束。
核心解决思路：分片 + 控制单次长度
不靠调大 MySQL 配置硬扛，而是让每次插入的数据量落在安全范围内（推荐 200–500 条），既稳定又易排查：
- 用
array_chunk($data, 500)把原始数组切分成每块最多 500 条的子数组 - 外层加
Db::startTrans()，循环内对每个子数组调用Db::name('table')->insertAll($chunk) - 每批执行后检查返回值（影响行数），任一批失败立即
rollback()，避免脏数据 - 别在循环里反复
commit()，也别把全部数据包进一个事务——折中选每 500～1000 条提交一次
确认并合理调整 MySQL 配置
分片是首选，但配置也要同步核对，防止低配环境连 200 条都撑不住：
- 登录 MySQL 执行
SHOW VARIABLES LIKE 'max_allowed_packet';，查看当前值（默认通常为 4194304 字节，即 4MB） - 若业务确实需要偶尔大包（如离线导入），可临时提升：
SET GLOBAL max_allowed_packet = 67108864;（64MB），但需 SUPER 权限 - 长期依赖调大配置不推荐——它不能解决锁表、内存暴涨、失败难回滚等问题；分片才是可持续方案
绕过模型层，用 Db::insertAll() 直接操作
如果用了模型的 saveAll()，尤其在 TP6 中，它默认是循环单条执行，反而更容易因多次往返触发连接超时或累积报错；换成原生查询类更可控：
立即学习“PHP免费学习笔记（深入）”；
- 构造字段名与数据库列完全一致的二维数组（例如用
create_time而非created_at） - 调用
Db::name('user')->insertAll($chunk, false)，第二个参数false跳过字段检测，减少开销 - 避免使用
saveAll()处理大批量数据，它在 TP6 是语法糖，不是真批量
其他容易忽略的细节
有些问题看似是 max_allowed_packet，实则由关联因素引发：
- 确保传入
insertAll的是连续数字索引数组，否则 TP5/6 可能解析失败导致空 SQL 或报错；补救：插入前加$data = array_values($data); - 关闭调试模式（
app_debug = false）和 SQL 日志（Db::setLogLevel(0)），万级插入时日志写入会严重拖慢甚至卡死 - 字段含 JSON、长文本、Base64 图片等大数据时，单条记录体积陡增，此时应进一步收紧单批次数量（如压到 200 条以内）
