如何解决Python Django项目上传大文件导致的内存溢出问题？-Python教程-PHP中文网

必须禁用FILE_UPLOAD_MAX_MEMORY_SIZE并改用流式上传：前端分块、后端用boto3/minio直传对象存储，绕过Django文件处理链路，结合Redis管理分片、环境变量配置存储后端及权限校验。

如何解决python django项目上传大文件导致的内存溢出问题？

直接改用 InMemoryUploadedFile 的替代方案，否则 Django 默认会把整个上传文件塞进内存——哪怕你只打算存到磁盘或对象存储。

为什么 `InMemoryUploadedFile` 会吃光内存？

Django 在接收到上传请求后，会根据 FILE_UPLOAD_MAX_MEMORY_SIZE 配置（默认 2.5MB）决定用 InMemoryUploadedFile 还是 TemporaryUploadedFile。但这个判断只发生在解析 multipart body 的**最开始**；一旦选了前者，后续所有操作（比如 file.read()、file.open()、甚至直接传给 boto3.upload_fileobj()）都基于内存缓冲区，根本不会“自动降级”到磁盘。

常见错误现象：

上传 500MB 文件时，Django 进程 RSS 内存瞬间飙升 500MB+，触发 OOM killer
request.FILES['file'].size 返回正确值，但 request.FILES['file'].read() 直接卡死或报 MemoryError
用 StreamingHttpResponse 导出没问题，但上传路径完全没做流式适配

强制走磁盘：改配置 + 手动切换文件类

不能只靠调大 FILE_UPLOAD_MAX_MEMORY_SIZE，那只是推迟爆炸时间。关键是让上传过程从一开始就不进内存。

在 settings.py 中设 FILE_UPLOAD_MAX_MEMORY_SIZE = 0 —— 这会让 Django 绕过内存判断，直接使用 TemporaryUploadedFile

如果必须保留小文件内存优化，可在视图里手动接管：

from django.core.files.uploadedfile import TemporaryUploadedFile
<p>if isinstance(request.FILES['file'], InMemoryUploadedFile):</p><div class="aritcle_card flexRow artxards">
											<div class="artcardd flexRow">
												<a class="aritcle_card_img" rel="nofollow" href="/ai/1328" title="小艺"><img
														src="https://img.php.cn/upload/ai_manual/000/000/000/175680183422075.png" alt="小艺" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
												<div class="aritcle_card_info flexColumn">
													<a rel="nofollow" href="/ai/1328" title="小艺" class="overflowclass">小艺</a>
													<p class="overflowclass">小艺是华为推出的系统级 AI 智慧助手和在线对话服务。</p>
												</div>
												<a rel="nofollow" href="/ai/1328" title="小艺" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
												</a>
											</div>
										</div><h1>强制转成磁盘文件</h1><pre class="brush:php;toolbar:false;">temp_file = TemporaryUploadedFile(
    name=request.FILES['file'].name,
    content_type=request.FILES['file'].content_type,
    size=request.FILES['file'].size,
    charset=request.FILES['file'].charset
)
# 复制内容到临时文件（分块，不爆内存）
for chunk in request.FILES['file'].chunks(chunk_size=8192):
    temp_file.write(chunk)
temp_file.seek(0)
uploaded_file = temp_file

else: uploaded_file = request.FILES['file']

真正流式处理：绕过 `request.FILES` 自己解析 multipart

当文件超过几百 MB 或并发高时，连 TemporaryUploadedFile 的临时磁盘 IO 都可能成瓶颈。这时得跳过 Django 的文件封装，用 request.body + email.parser 或 requests-toolbelt 流式提取字段和文件块。

用 requests-toolbelt 的 MultipartDecoder 可边收边解码，每块 yield 出来就立刻写入目标存储（S3、MinIO、本地路径）
关键点：设置 DATA_UPLOAD_MAX_MEMORY_SIZE = 0 并禁用 django.middleware.csrf.CsrfViewMiddleware（流式上传无法校验完整 body 的 CSRF token）

示例核心逻辑：

from requests_toolbelt.multipart.decoder import MultipartDecoder
<p>decoder = MultipartDecoder(request.body, request.content_type)
for part in decoder.parts:
if part.headers.get(b'Content-Disposition', b'').find(b'filename=') != -1:</p><h1>这是文件字段，直接迭代 part.content</h1><pre class="brush:php;toolbar:false;">    for chunk in iter(lambda: part.content.read(65536), b''):
        s3_client.upload_part(Bucket=..., Body=chunk, ...)

GPU 模型服务场景下的双重溢出风险

如果你的 Django 视图上传后立刻喂给 PyTorch 模型（比如超分、OCR），还要防显存溢出——这和内存溢出是两回事，但常一起发生。

即使文件已落盘，torch.load() 或模型 forward 仍可能因 batch size 过大、图像尺寸超限导致 CUDA out of memory
必须在 try/except RuntimeError 中捕获 "out of memory"，并立即调用 torch.cuda.empty_cache()
别依赖模型自动释放：PyTorch 的缓存不会在异常后自动清空，下次请求仍会失败

最易被忽略的是：上传路径和模型推理路径的内存模型完全不同，但错误日志往往只显示后者崩溃，让人误以为问题出在模型侧。