每个分片需共用uploadId、独立chunkIndex（从0严格递增）和可选chunkHash；uploadId由前端生成UUID，chunkIndex通过for循环按chunkSize步进计算，避免浮点误差；参数优先走URL查询字符串。
怎么给每个分片加唯一标识
分片上传必须靠标识区分顺序和归属，否则服务端拼接时会乱序或覆盖。核心是：同一文件所有分片共用一个 uploadId，每个分片带独立的 chunkIndex（从 0 或 1 开始）和 chunkHash（可选，用于校验）。
-
uploadId建议前端生成（如 UUID），在第一个分片请求前就确定，并随所有分片一起发送 -
chunkIndex必须严格递增，推荐从0开始——后端按索引合并时更直观，避免边界计算错误 - 别用文件名或时间戳当标识：重名文件、毫秒级并发都会冲突
- 如果服务端要求
totalChunks，务必在首分片或预检接口中传全，不能靠客户端算完再发——浏览器可能中断，File.size在某些压缩包或 Blob 场景下不准
HTTP 请求里怎么传分片编号
没有标准方式，但实际开发中 90% 的后端期望走 URL 查询参数或表单字段，而非自定义 Header。Header 容易被代理截断或大小受限，且不方便 Nginx 日志调试。
- URL 方式最稳妥：
/upload?uploadId=abc123&chunkIndex=5&totalChunks=12 - Body 表单方式（
multipart/form-data）可传chunkIndex字段，但注意：部分后端框架（如 Express +multer）默认不解析非文件字段，得显式开启fields配置 - 绝对不要把编号塞进
Content-Range头里试图“伪装”成断点续传——那属于 RFC 7233 范畴，和业务分片逻辑无关，服务端通常不认
前端切片时常见的 index 错误
错位一帧，后端就拼出损坏文件。根本原因是 File.slice() 和索引计数没对齐，尤其在动态调整分片大小时。
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 别用
Math.ceil(file.size / chunkSize)算总片数再循环——浮点误差会让最后一片偏小，chunkIndex却还是递增，导致服务端等一个不存在的片 - 正确做法：用
for (let i = 0; i * chunkSize ，每次取 <code>file.slice(i * chunkSize, (i + 1) * chunkSize) - 如果用户拖拽多个文件，每个文件必须有独立
uploadId，不能复用——否则不同文件的分片混在同一个上传队列里，chunkIndex就彻底失效 - 暂停续传时，别重置
i计数器；要从上次成功的chunkIndex继续，否则重复上传或跳片
后端验证分片标识时最容易忽略的点
前端传的 chunkIndex 是字符串，后端不转成数字直接比大小，"10" 会返回 true。
立即学习“前端免费学习笔记（深入）”；
- Node.js 里用
parseInt(req.query.chunkIndex, 10)，别用Number()或一元加号——空字符串变0，"1a"变1，埋下越界风险 - 必须校验
chunkIndex >= 0 && chunkIndex ，漏掉 <code> 会导致数组越界写入或磁盘爆满 - Redis 缓存
uploadId元数据时，别设永不过期——用户关浏览器后残留元数据会锁死后续同名上传 - 合并完成后的清理动作（删临时分片文件、清 Redis）必须放在 finally 块里，异常也不能跳过，否则磁盘悄悄吃满
分片标识看着简单，真正上线后出问题，八成卡在 index 类型转换、uploadId 生命周期、或并发下的状态竞争——这些地方没日志，查起来特别慢。
