现场是这样的。把 45 万条短请求写成一个 jsonl，文件 312MB，用 Files API 上传时回 400，原文是 file is too large: maximum size is 256 MB，压成 gz 又被拒，提示不支持该类型。
中间走过弯路，把「单行过长会被单独拦下」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。单文件上限是 256MB；压缩包不在允许的 MIME 列表里；拆开后没同步 custom_id 与分片的对应关系。
上来先看当前文件大小与行数
python -c "import os;print(os.path.getsize('batch.jsonl')//1024//1024,'MB')"随后按体积切分 每片控制在 200MB 以内
python split_by_size.py --in batch.jsonl --mb 200 --prefix part再往下逐片上传并记录 file_id
python upload_parts.py --dir parts --out file_ids.json提交后核对总条数
python submit_batches.py --files file_ids.json --expect 450000这类问题以前遇到过，但这次的触发条件和上次不一样。
这类改动我都写进变更记录，过两周再出问题时能对上号。
别只看报错消失，验证要多做一步。三片都上传成功，批次总条数与源文件行数一致，没有出现 too large。
按体积切要保证每行完整，按行号硬切会写出半条 JSON，读回来第一行就解析失败。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。