Flask接收前端分片Blob需用request.files['file'].read()立即读取字节，避免请求体被消耗；分片应追加写入临时文件并记录已接收索引，合并前校验哈希，完成后原子重命名，并定时清理过期.part文件。
Flask 怎么接收前端传来的分片 Blob？
前端用 File.prototype.slice() 或 Blob.slice() 切分后，通常以 FormData 发送，每个分片带固定字段（如 file、chunkIndex、totalChunks、fileName）。Flask 侧不能直接用 request.files.get('file') 就完事——它能拿到，但必须立刻读取内容，否则后续请求体被丢弃，导致后续分片读不到。
- 务必用
request.files['file'].read()拿到原始字节，别依赖.save()，它内部会调用read()但可能干扰流状态 - 前端若用
fetch+FormData，确保没手动设置Content-Type头，否则 Flask 解析multipart/form-data会失败，报400 Bad Request - 分片标识建议统一用整数
chunkIndex（从 0 开始），避免前端传字符串"0"导致 Python 比较出错
怎么安全地把分片追加写入同一个临时文件？
不能每个分片都 open(..., 'w') 覆盖写，也不能全加载进内存再拼——大文件（比如 2GB 视频）会 OOM。正确做法是用 open(..., 'ab') 追加，并按 chunkIndex * chunkSize 控制写入位置。但注意：HTTP 请求无序，分片可能乱序到达。
- 先用
fileName+totalChunks生成唯一临时文件名（例如f"{safe_name}_{total_chunks}.part"），避免不同用户同名文件冲突 - 写入前检查该分片是否已存在（可建个
{chunkIndex: True}的 Redis 或本地 JSON 记录），防止重复写入损坏文件 - 不要用
seek()定位写入——分片大小不严格相等（最后一块更小），seek容易偏移，老老实实追加 + 外部记录顺序更稳
request.files 读取后为什么下个分片就拿不到数据？
这是 Flask（基于 Werkzeug）的底层行为：请求体只能被消费一次。request.files、request.form、request.get_data() 任意一个触发读取，其余就会返回空。常见错误是先 print request.form 调试，再取 request.files，结果后者为空。
- 调试时改用
request.get_data(cache=True)一次性缓存原始 body，再用ImmutableMultiDict手动解析 multipart（需引入werkzeug.formparser），但太重——推荐直接用request.files和request.form，且只用一次 - 如果必须同时访问 form 和 files，确保顺序是：先取
request.files并.read()，再取request.form；反过来就会失败 - 用
curl -F测试时，别加-H "Content-Type: ..."，让 curl 自动设 boundary
合并完成后的文件怎么校验完整性？
前端传的 totalChunks 和 chunkIndex 只能防漏，不能防损坏。真正可靠的是哈希比对：前端上传前算整个文件的 md5 或 sha256，传给后端；合并完再算一次临时文件的哈希。
立即学习“前端免费学习笔记（深入）”；
- 别在内存里读全文件算哈希——用
hashlib.md5()分块更新：for chunk in iter(lambda: f.read(8192), b'') - 合并动作本身要原子化：先写到
xxx.part，校验通过后再os.replace()成正式文件，避免程序崩溃时留下半成品 - 生产环境务必加超时清理：用定时任务扫
*.part文件，超过 24 小时未完成的直接删，不然磁盘会被占满
实际最难的不是分片逻辑，是处理网络中断后前端重传、服务重启时分片状态丢失、以及多进程部署下共享临时状态的问题——这些没法靠单个 Flask route 解决，得靠外部存储兜底。
