如何使用Django实现大文件分片上传及存储后的合并处理?
- 内容介绍
- 文章标签
- 相关推荐
本文共计1038个文字,预计阅读时间需要5分钟。
由于Django默认将整个上传体读入内存,再添加`request.FILES`,遇到几百MB乃至GB级别的文件,会超时或导致OOM(MemoryError)。或者被Nginx/Apache的`client_max_body_size`或`LimitRequestBody`参数挡在网关外。这并不是Django不能处理大文件的问题,而是它没有机会将整个数据读入内存。
所以分片是必须的——前端切块、后端逐块接收、最后合并。Django 本身不提供分片逻辑,得自己搭骨架。
- 别指望
FileField自动支持分片:它只认完整文件对象 - Nginx 默认限制 1MB,要调大
client_max_body_size 2048m(同时配好proxy_buffering off和超时) - 浏览器
fetch或XMLHttpRequest发送分片时,务必带唯一upload_id和当前chunk_index,否则后端无法拼序
怎么设计分片上传接口(基于 Django View)
你需要一个接受单个分片的 endpoint,比如 /api/upload/chunk/,它不做校验、不合并,只存临时块。关键点在于:如何避免并发写冲突、怎么定位属于哪个上传任务、以及临时文件存在哪。
- 用
upload_id(如 UUID)作为临时目录名,每个上传任务独占一个子目录,路径类似/tmp/uploads/{upload_id}/chunk_0001 - 分片文件名建议固定格式:
chunk_{index:04d},方便后续按字典序合并 - 不要用数据库存每一块的路径——IO 太重;但要用 DB 记一条主记录:
UploadTask(upload_id, filename, total_chunks, status) - 接收时检查
Content-Range头或显式传chunk_index,防止前端乱序发送导致覆盖
def upload_chunk(request): if request.method != "POST": return JsonResponse({"error": "Method not allowed"}, status=405) upload_id = request.POST.get("upload_id") chunk_index = int(request.POST.get("chunk_index", 0)) chunk_file = request.FILES.get("file") # …… 存到 /tmp/uploads/{upload_id}/chunk_{chunk_index:04d}
合并分片时为什么 cat 比 Python open().write() 更稳
Python 逐块 read()/write() 合并大文件,容易因缓冲区、编码、换行符或 seek() 错误导致内容错位;而系统级 cat 是纯二进制流拼接,无解析开销,也避开了 Python GIL 和内存压力。
- 用
subprocess.run(["cat"] + chunk_paths, stdout=fout)前,先确认所有chunk_*文件存在且大小非零 - 合并完立刻校验总大小是否等于预期:
os.path.getsize(final_path) == expected_size - 别在合并中途删分片——万一失败就丢数据;建议合并成功后再批量
rm -f临时目录 - 如果部署在 Windows,改用
copy /b,但更推荐统一 Linux 环境,避免跨平台陷阱
上传完成后怎么安全触发存储到 S3 或 MinIO
合并完成只是本地落盘,真正上传到对象存储是另一阶段。不能在合并后同步调用 boto3.client.upload_file(),否则阻塞请求、拖慢响应、还可能超时。
- 必须异步:用
celery或django-rq把上传任务扔进队列,返回{"status": "processing", "upload_id": "xxx"} - 异步任务里先校验本地文件哈希(如
hashlib.md5()),再调s3_client.upload_file(),成功后更新 DB 中status="completed" - 别把 AWS 凭据硬编码或放环境变量泄露——用 IAM role(EC2)或
~/.aws/credentials(开发) - MinIO 要确保
endpoint_url末尾不带/,否则boto3会拼出双斜杠导致签名失败
最易被忽略的是清理时机:临时分片目录得靠异步任务收尾时删,而不是前端收到“上传成功”就删——那会删掉还没开始上传的对象存储任务所依赖的源文件。
本文共计1038个文字,预计阅读时间需要5分钟。
由于Django默认将整个上传体读入内存,再添加`request.FILES`,遇到几百MB乃至GB级别的文件,会超时或导致OOM(MemoryError)。或者被Nginx/Apache的`client_max_body_size`或`LimitRequestBody`参数挡在网关外。这并不是Django不能处理大文件的问题,而是它没有机会将整个数据读入内存。
所以分片是必须的——前端切块、后端逐块接收、最后合并。Django 本身不提供分片逻辑,得自己搭骨架。
- 别指望
FileField自动支持分片:它只认完整文件对象 - Nginx 默认限制 1MB,要调大
client_max_body_size 2048m(同时配好proxy_buffering off和超时) - 浏览器
fetch或XMLHttpRequest发送分片时,务必带唯一upload_id和当前chunk_index,否则后端无法拼序
怎么设计分片上传接口(基于 Django View)
你需要一个接受单个分片的 endpoint,比如 /api/upload/chunk/,它不做校验、不合并,只存临时块。关键点在于:如何避免并发写冲突、怎么定位属于哪个上传任务、以及临时文件存在哪。
- 用
upload_id(如 UUID)作为临时目录名,每个上传任务独占一个子目录,路径类似/tmp/uploads/{upload_id}/chunk_0001 - 分片文件名建议固定格式:
chunk_{index:04d},方便后续按字典序合并 - 不要用数据库存每一块的路径——IO 太重;但要用 DB 记一条主记录:
UploadTask(upload_id, filename, total_chunks, status) - 接收时检查
Content-Range头或显式传chunk_index,防止前端乱序发送导致覆盖
def upload_chunk(request): if request.method != "POST": return JsonResponse({"error": "Method not allowed"}, status=405) upload_id = request.POST.get("upload_id") chunk_index = int(request.POST.get("chunk_index", 0)) chunk_file = request.FILES.get("file") # …… 存到 /tmp/uploads/{upload_id}/chunk_{chunk_index:04d}
合并分片时为什么 cat 比 Python open().write() 更稳
Python 逐块 read()/write() 合并大文件,容易因缓冲区、编码、换行符或 seek() 错误导致内容错位;而系统级 cat 是纯二进制流拼接,无解析开销,也避开了 Python GIL 和内存压力。
- 用
subprocess.run(["cat"] + chunk_paths, stdout=fout)前,先确认所有chunk_*文件存在且大小非零 - 合并完立刻校验总大小是否等于预期:
os.path.getsize(final_path) == expected_size - 别在合并中途删分片——万一失败就丢数据;建议合并成功后再批量
rm -f临时目录 - 如果部署在 Windows,改用
copy /b,但更推荐统一 Linux 环境,避免跨平台陷阱
上传完成后怎么安全触发存储到 S3 或 MinIO
合并完成只是本地落盘,真正上传到对象存储是另一阶段。不能在合并后同步调用 boto3.client.upload_file(),否则阻塞请求、拖慢响应、还可能超时。
- 必须异步:用
celery或django-rq把上传任务扔进队列,返回{"status": "processing", "upload_id": "xxx"} - 异步任务里先校验本地文件哈希(如
hashlib.md5()),再调s3_client.upload_file(),成功后更新 DB 中status="completed" - 别把 AWS 凭据硬编码或放环境变量泄露——用 IAM role(EC2)或
~/.aws/credentials(开发) - MinIO 要确保
endpoint_url末尾不带/,否则boto3会拼出双斜杠导致签名失败
最易被忽略的是清理时机:临时分片目录得靠异步任务收尾时删,而不是前端收到“上传成功”就删——那会删掉还没开始上传的对象存储任务所依赖的源文件。

