先看现象。上传 jsonl 时 purpose 传 batch，上传返回 200 并给了 id，但业务代码调 /v1/files 列表时查不到，判定文件不存在又传了一遍，一天重复上传了 40 次。
这类报错背后常见的原因有几处，逐个排除就行。列表接口默认只返回 assistants 用途的文件。还有一种是分页默认只取前 100 条，目标文件在后面。
不容易想到的是，purpose 与后续调用的接口要求不一致。
还有一种情况，文件被 TTL 策略提前清理。
先查列表时显式带上 purpose
curl -s 'https://api.openai.com/v1/files?purpose=batch&limit=100' -H "Authorization: Bearer $KEY" | jq -r '.data[] | [.id,.filename] | @tsv'随后按已知 id 直接查这一条
curl -s https://api.openai.com/v1/files/file_abc123 -H "Authorization: Bearer $KEY" | jq '{id:.id, purpose:.purpose, status:.status}'接着把去重判断改成按文件名加哈希
python dedupe_upload.py --dir inbox --hash sha256 --state uploaded.json剩下的就是清理重复上传的残留文件
curl -X DELETE https://api.openai.com/v1/files/file_dup01 -H "Authorization: Bearer $KEY"同样的操作我在测试机上先走了一遍，线上只做验证过的部分。
改完先别撤，确认这几项。带 purpose 的列表能查到这批文件，按哈希去重后重复上传次数归零，列表里只剩一份。
列表接口的默认过滤条件经常被忽略，判断文件是否存在要用 id 直查，不要用列表结果反推。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。