uni.uploadFile 不支持断点续传是硬限制，因其黑盒封装、无进度回调、无法获取已上传字节、不支持分片与Range头，须改用分片上传+服务端协同方案。
uni.uploadFile 不支持断点续传，这是硬限制。所有平台（H5、小程序、App）下它都是黑盒封装，不暴露上传进度、暂停/恢复能力，也无法控制分片或读取已上传字节偏移量。想靠它实现断点续传，注定失败。
为什么 uni.uploadFile 不能做断点续传
根本原因在于它不提供底层控制权：
- 没有
onUploadProgress的可靠回调（App 端基本不可用，小程序返回值不稳定） - 无法获取当前已上传字节数，中断后无从知道“传到哪了”
- 不支持设置
Range请求头（下载场景）或分片标识（上传场景） - 错误码模糊：
fail abort可能是用户取消、切后台、系统 kill，JS 层无法区分
上传断点：必须用分片 + 服务端协同（H5 / 小程序 / App 各有路径）
核心不是“怎么发”，而是“怎么管状态”——客户端要能查、能跳、能存、能续。
- H5 环境优先用
File.slice()分片，配合fetch或XMLHttpRequest手动发请求，每片带chunkIndex和chunkMd5 - 小程序端不能直接读文件局部字节，得先用
uni.getFileSystemManager().readFile配合position和length分段读，否则大文件易内存溢出 - App 端别碰
uni.uploadFile，改用plus.uploader.createUpload，它支持手动分片、自定义 header（如X-Part-Number）、监听单片状态 - 所有平台都必须在上传前调用
/api/upload/init接口，传fileMd5+fileName，拿到uploadId和已传分片列表（如[0,2,4]） - 上传中状态必须存进
uni.setStorageSync，但注意：要JSON.stringify再存，否则读出来是[object Object]
下载断点：靠 Range + 本地文件追加写入
下载断点续传依赖 HTTP Range 头和服务端 206 响应，客户端负责检查本地文件长度并追加写入。
- 先用
uni.getFileSystemManager().getFileInfo查目标文件是否存在及大小，得到size - 发起
uni.request时，在header中加{"Range": "bytes=" + size + "-"} - 服务端必须支持
Range，返回状态码为206 Partial Content；若返回200，说明不支持，需清空重下 - 收到响应后，用
uni.getFileSystemManager().writeFile的append: true模式写入（H5 不支持该参数，需自行用Blob合并） - 别用
uni.downloadFile实现断点——它不支持Range，也不允许追加写入，只能重头来
容易被忽略的三个关键点
很多实现卡在最后一步，不是逻辑错，而是细节失控：
- 服务端没做原子性校验：分片写入临时目录后，必须同步更新数据库/Redis 记录，否则并发上传可能覆盖或丢失状态
- 客户端没做“状态再拉取”：恢复上传前，必须重新请求
/api/upload/status?uploadId=xxx，不能只信本地缓存——服务端可能清理了超时分片 - App 切后台后 JS 上下文可能被回收，
plus.uploader实例失效，所有进度必须落地到本地存储，且建议加时间戳防旧状态覆盖新任务
