cloudfile.delete 批量删除必须分片、串行重试、控制并发，因阿里云限100个fileid且易413错误，腾讯云虽支持1000个但超时丢弃风险高；推荐每批50个、重试2次、校验fileid合法性，并优先按前缀调用原生sdk删除。
直接调用 cloudfile.delete 一次性删几千个文件，大概率失败或超时——这不是你代码写错了，是 uniCloud 云存储批量删除本身有硬性限制，必须分片、加重试、控并发。
为什么 cloudfile.delete 批量删会失败
uniCloud 的 cloudfile.delete 接口底层调用各云厂商（阿里云/腾讯云）的 OSS/COS 删除 API，但 uniCloud SDK 封装层未做自动分片。当传入超过 100 个 fileID 时：
- 阿里云版：请求体过大，直接返回
413 Request Entity Too Large - 腾讯云版：虽支持最多 1000 个对象，但网络抖动 + 单次响应超时（默认 5s）极易导致部分成功、部分静默丢弃
- 无论哪一家，
Promise.all并发删 500+ 文件，失败后难以定位哪个fileID没删掉，也难补删
分片 + 串行重试是最稳的实操路径
别碰 Promise.all 全量并发，也别信“一次传 999 个就能省事”。生产环境验证过的做法是：固定每批 50 个，串行执行，失败自动重试 2 次，跳过已不存在的文件。
示例代码（云函数中）：
exports.main = async (event, context) => {
const { fileList = [] } = event;
const batchSize = 50;
const maxRetry = 2;
const db = uniCloud.database();
<p>for (let i = 0; i ({ fileID: id }))
});
break; // 成功就跳出重试循环
} catch (e) {
if (retry === maxRetry || !e.message.includes('NoSuchKey')) {
console.error(<code>批次 ${i/batchSize + 1} 删除失败，fileIDs:</code>, batch, e);
throw e;
}
retry++;
await new Promise(r => setTimeout(r, 500 * retry)); // 指数退避
}
}
}
return { deleted: fileList.length };
};</p>
-
fileID数组必须是对象数组，格式为[{fileID: 'xxx'}, {fileID: 'yyy'}]，不能只传字符串数组 - 阿里云版不支持
cloudfile.delete批量传参，必须用uniCloud.uploadFile配合fileID数组模拟删除（这是当前最兼容的写法） - 腾讯云版可直接用
cloudfile.delete({ fileList })，但依然要分片，且需捕获NoSuchKey错误——它表示文件已被删或不存在，可安全跳过
删前务必先 list 再校验，别靠前端传来的 fileID 列表
用户或前端可能传重复、已删、格式错误的 fileID，直接删会浪费请求配额甚至触发风控。正确流程是：
- 先调
cloudfile.list({ prefix: 'user/123/' })拿真实存在的文件列表 - 用
fileList.fileList.map(f => f.fileID)提取干净 ID，再和前端传入的做交集（避免删错目录） - 对每个
fileID做基础校验：/^[a-zA-Z0-9_-]{10,64}$/.test(id)，过滤明显非法值 - 特别注意：阿里云
fileID是 URL-safe base64 字符串，含-和_；腾讯云则是标准 UUID 格式，二者混用会导致 404
大文件清理场景下，优先考虑按前缀删而非枚举 fileID
如果目标是清空某个用户上传目录（如 user/8888/avatar/），不要先 list 再逐个 delete——这在文件量 >1w 时 I/O 开销巨大。更优解是：
- 腾讯云 COS：调用
cos.deleteMultipleObject（原生 SDK），传prefix+Quiet: true，它内部自动分页处理 - 阿里云 OSS：用
oss.deleteObjects（原生 SDK），配合delimiter: '/'和prefix，效率比 list+delete 高 5–8 倍 - uniCloud 层不暴露这些能力，所以得在云函数里手动引入对应云厂商 SDK，并配置好密钥——这意味着你得放弃跨云部署一致性，但性能提升显著
真正卡点不在代码怎么写，而在你是否愿意为清理动作单独建一个「运维型」云函数，而不是塞进业务逻辑里凑合用。
