就爱读必须禁用FILE_UPLOAD_MAX_MEMORY_SIZE并改用流式上传：前端分块、后端用boto3/minio直传对象存储，绕过Django文件处理链路，结合Redis管理分片、环境变量配置存储后端及权限校验。
直接改用 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
if isinstance(request.FILES['file'], InMemoryUploadedFile):
强制转成磁盘文件
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_fileelse:
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
decoder = MultipartDecoder(request.body, request.content_type) for part in decoder.parts: if part.headers.get(b'Content-Disposition', b'').find(b'filename=') != -1:
这是文件字段，直接迭代 part.content
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 的缓存不会在异常后自动清空，下次请求仍会失败
最易被忽略的是：上传路径和模型推理路径的内存模型完全不同，但错误日志往往只显示后者崩溃，让人误以为问题出在模型侧。
