Python项目中怎么解决Django上传大文件导致内存飙升的问题？-Python教程-PHP中文网

必须禁用django默认内存缓冲并流式读取request.body，否则100mb+文件上传会触发memoryerror或被gunicorn/nginx杀进程；因request.files底层强制将整个multipart请求体载入内存或临时磁盘，无法支撑大文件。

python项目中怎么解决django上传大文件导致内存飙升的问题？

直接禁用 Django 默认的内存缓冲机制，改用流式读取 request.body，否则 100MB+ 文件上传必然触发 MemoryError 或被 Gunicorn/Nginx 杀掉进程。

为什么 `request.FILES` 会让内存爆掉

Django 的 request.FILES 底层会把整个 multipart 请求体先加载进内存（InMemoryUploadedFile）或写入临时磁盘再读（TemporaryUploadedFile）。这两种方式对大文件都不可行：前者吃光内存，后者产生大量 I/O 和重复读写。哪怕你只上传一个 200MB 视频，Django 还没进视图函数，WSGI 服务器可能已经中断连接了。

常见错误现象包括：

MemoryError 或 Killed: 9（Linux OOM killer 干掉进程）
Nginx 返回 413 Request Entity Too Large
Gunicorn 日志里出现 Worker timeout 或 Worker failed to boot

根本不是代码写错了，是默认路径就不支持大文件。

必须在视图开头设 `request.upload_handlers = []`

这个操作强制 Django 跳过所有 UploadHandler（包括内存和临时文件处理器），让 request.body 保持原始字节流状态。不加这句，后续任何 request.body.read() 都可能失败或返回空。

实操要点：

必须放在视图函数最开始，且仅对 POST/PUT 请求做；GET 请求没有 body，别乱设
设完之后不能再访问 request.POST 或 request.FILES，否则会触发解析异常
如果你用了 Django REST Framework，APIView 类里要重写 initialize_request 或直接在 dispatch 中处理

示例片段：

python全能编程助手

SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的双功能合体技能，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途：；核心要点📝 题解模式：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式：输入 Python 代码，自动添加详细中。它将相关步骤、

下载

def upload_stream_view(request):
    if request.method != 'POST':
        return JsonResponse({'error': 'only POST'})
    request.upload_handlers = []  # 关键！
    file_path = '/tmp/upload.bin'
    with open(file_path, 'ab') as f:
        for chunk in iter(lambda: request.body.read(8192), b''):
            f.write(chunk)
    return JsonResponse({'size': os.path.getsize(file_path)})

分块上传时怎么避免后端拼错文件

前端用 File.slice() 分片后，后端不能靠请求到达顺序来合并——HTTP 并发下 chunkIndex=5 完全可能比 chunkIndex=2 先到。必须用业务参数严格对齐。

关键控制点：

前端每个请求必须带 identifier（建议用文件名+大小+时间戳哈希）、chunkIndex（从 0 开始）、totalChunks
后端保存路径应为 media/chunks/{identifier}/{chunkIndex}.part，而不是简单追加
合并前必须检查是否所有 .part 文件都存在，且用 os.path.getsize() 校验每块大小是否匹配预期
合并动作不要自动触发，必须由独立接口（如 POST /api/merge/）显式调用，防止前端中断导致状态不一致

注意：request.content_type 应为 application/octet-stream，不是 multipart/form-data；若前端仍发表单格式，后端解析会失败。

对象存储直传为什么不能靠 `django-storages`

django-storages 只接管“存到哪”，不改变“怎么传上来”。它依然依赖 UploadedFile 对象，而这个对象默认就是走内存或临时文件——等于绕了一圈又回到原点。

真正直传 MinIO/S3 的做法是：

前端分块上传，后端用 boto3.client('s3').upload_fileobj() 或 minio.Minio.put_object() 直接推流
禁用 FILE_UPLOAD_MAX_MEMORY_SIZE（设为 0），并确保 Nginx 的 client_max_body_size 足够大
MinIO 必须显式传 secure=False，否则 HTTPS 握手失败；S3 推荐用 Config(signature_version='s3v4')
object key 命名要用唯一前缀（如 f"{uuid4()}/{original_name}"），避免覆盖和冲突