直接用request.files处理tb级文件会失败，因为django默认将整个请求体读入内存或临时文件，而大文件上传易受网络中断影响导致数据不完整，且http协议本身缺乏分片校验与断点定位能力，必须由额外协议层补足。
为什么直接用 request.FILES 会失败
大文件上传时，Django 默认把整个请求体读进内存或临时文件，一旦中断（比如网络抖动、浏览器刷新），request.FILES 就拿不到完整数据，后续再传同名文件会被当成全新上传，无法复用已传部分。这不是 Django 的 bug，而是 HTTP 协议本身不带“分片校验+断点定位”能力，必须靠额外协议层补足。
- 客户端必须按固定大小切片（如 5MB/片），每片带唯一
chunkNumber、totalChunks、identifier（通常用文件名+哈希生成） - 服务端不能依赖
request.FILES原始解析，要手动读取request.body或request.read()获取原始二进制流 - 上传路径需脱离 Django 的表单解析流程，改用
POST接口直收裸数据
如何用 django.views.View 手动处理分片
绕过 Form 和 request.FILES，用类视图直接操作原始请求体是最可控的方式。关键点在于：识别分片元信息、拼接逻辑、避免并发写冲突。
- 从
request.POST.get('chunkNumber')、request.POST.get('identifier')提取分片上下文，不要信任Content-Disposition中的 filename - 用
identifier作为临时存储目录名（如/tmp/uploads/{identifier}/），每个分片存为{chunkNumber}.bin - 写入前加文件锁（
flock或 Redis 分布式锁），否则多线程/多进程同时写同一分片可能损坏数据 - 最后合并时用
cat /tmp/uploads/{id}/*.bin > /data/uploads/{final_name}或 Python 的open(..., 'ab')追加，别用内存拼接
upload/merge 接口怎么判断是否全部分片到位
不能只看分片文件数量等于 totalChunks，还要验证每个编号是否存在且大小正确——用户可能跳传、重传或传错编号。
- 遍历
range(1, totalChunks + 1)，检查{chunkNumber}.bin文件是否存在且非空 - 可选校验：对每个分片算
sha256并比对客户端传来的chunkHash（需前端配合） - 合并成功后立即删除整个临时目录，避免磁盘占满；失败则保留目录供重试，但设 TTL（如 24 小时）自动清理
- 返回状态码用
200表示合并完成，206 Partial Content表示还缺分片，409 Conflict表示校验失败
生产环境必须处理的三个隐藏陷阱
本地跑通不等于线上可用。Nginx、uWSGI/Gunicorn、Django 中间件都会悄悄吞掉或限制大请求，导致分片传到一半就卡住。
- Nginx 需显式配置：
client_max_body_size 2G;、proxy_buffering off;、proxy_request_buffering off;（后者防止 Nginx 缓存整个请求体） - uWSGI 要关掉
--buffer-size限制或调大，Gunicorn 则需--limit-request-body 0（禁用限制） - Django 中间件如
SecurityMiddleware的XSS过滤可能误杀二进制分片头，建议在上传路径上exclude该中间件
临时目录权限、磁盘空间监控、分片超时清理——这些不是“做完就能跑”，而是上线前必须压测并写进运维 checklist 的东西。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
