continue不直接跳过已上传块，而是根据服务端校验结果在循环中跳过已成功分片；需先调用/check接口确认状态，仅当服务端返回uploaded: true时才执行continue。
在大文件分片上传中，continue 本身不直接“跳过已上传的块”，而是配合服务端校验结果，在循环遍历分片时跳过当前迭代，避免重复上传已确认成功的分片。
先校验分片上传状态，再决定是否 continue
核心逻辑是：客户端（如浏览器）在上传前，主动向服务端发起一个「查询分片状态」请求（例如 /upload/check?fileId=xxx&chunkIndex=5），服务端返回该分片是否已存在且完整。若已存在，就用 continue 跳过本次上传处理。
- 不要依赖本地缓存或文件名判断——可能不准；必须以服务端权威状态为准
- 检查接口应轻量、幂等，响应建议只含布尔值或简单状态码（如
{ "uploaded": true }） - 网络失败或超时需谨慎处理，不能默认跳过，应按错误策略重试或中断
典型 for 循环中的 continue 使用示例
假设你用 JavaScript 按顺序上传 0~99 号分片：
for (let i = 0; i <p>这里 <code>continue</code> 让循环立刻进入下一轮，不执行上传和进度逻辑，既节省带宽也避免服务端重复写入。</p> <h3>注意边界与一致性保障</h3> <p>跳过已传分片只是优化手段，不能替代整体一致性机制：</p>
- 服务端仍需对每个上传请求做幂等校验（如比对分片 hash 或 etag）
- 客户端需处理「查询状态成功但上传实际失败」的竞态（例如查询后服务端崩溃丢失数据），建议搭配最终合并前的完整性校验（如合并时校验所有分片 hash 列表）
- 若支持断点续传，还需记录最后成功上传的索引，避免每次从头查 —— 但首次仍建议全量校验，防止本地记录被篡改
其他语言/场景中的等效思路
Python、Java 等同样适用：continue 是循环控制语句，本质不变。重点在于「何时判断」「判断依据是否可靠」：
- Python 示例：
if await is_chunk_uploaded(file_id, idx): continue - 关键不是语法，是把「状态查询 + 条件跳过」作为标准步骤嵌入上传流程
- 若用 Web Worker 或多线程并发上传，
continue不适用，应改用条件过滤（如filter().map(...)）或任务队列调度
