超时是nginx、wsgi服务器和django三层共同导致的：nginx因client_body_timeout或client_max_body_size限制先中断；gunicorn/uvicorn超时设置不当再中断；django默认multipart解析无法流式处理大文件，需禁用upload_handlers并裸读body或分片上传。
超时不是 Django 单独造成的，而是整个请求链路中多个环节共同“掐断”连接的结果：Nginx 先拦、WSGI 服务器再杀、Django 最后收不到完整 body —— 你看到的 UnreadablePostError 或空文件，往往是其中某一层已提前终止了请求。
为什么 Nginx 会先中断大文件上传
Nginx 默认对客户端上传行为极其保守：它不信任长连接，也不缓冲大请求体。一旦上传时间超过 client_body_timeout（默认 60 秒），或总大小超过 client_max_body_size（默认 1MB），它就直接返回 413 Request Entity Too Large 或静默关闭连接。
-
client_max_body_size必须显式设为足够值，比如100M；仅调 Django 的DATA_UPLOAD_MAX_MEMORY_SIZE没用 -
client_body_timeout和proxy_read_timeout都要同步延长，否则 Nginx 在读取 body 过程中就会超时 - 如果用了 HTTPS，还要检查
ssl_buffer_size是否过小（默认 4k），导致 TLS 分片频繁，加剧超时风险
为什么 Gunicorn / Uvicorn 也会强制中断
WSGI/ASGI 服务器本身有独立的请求读取超时机制。Gunicorn 的 --timeout（默认 30 秒）是从接收到第一个字节开始计时；Uvicorn 的 --timeout-keep-alive 和 --limit-max-requests 同样会影响长上传。
- Gunicorn 中，
--timeout值必须 > Nginx 的proxy_read_timeout，否则它会在 Nginx 还没传完时就 kill worker - 使用
--preload可能加剧问题：worker 预加载后更早进入 timeout 计时，建议关闭 - Uvicorn 在
http://模式下比https://更稳定；若必须用 HTTPS，确保证书链完整、OCSP stapling 开启，避免握手延迟拖垮上传
为什么 Django 自身也“帮倒忙”
Django 不是“不支持大文件”，而是它的默认路径（request.FILES + multipart 解析）天然不适合大文件：它依赖中间件逐层读取、解析整个请求体，而这个过程无法中断重试，也无法流式跳过无关字段。
- 设置
request.upload_handlers = []是绕过 multipart 解析的硬性前提；否则哪怕你手动读request.body，Django 仍会尝试解析并失败 -
DATA_UPLOAD_MAX_MEMORY_SIZE控制的是“整个请求体最大内存占用”，不是文件大小上限；设太大反而容易 OOM，建议保持默认或略增（如52428800即 50MB） - CSRF 中间件会对所有 POST 请求校验 token，但大文件上传时 token 可能因超时丢失或被丢弃——可在上传视图上加
@csrf_exempt，或改用基于签名的 token 方案
真正有效的上传路径只有两条
要么前端分片（chunk）、后端合并，要么后端裸读 request.body 流式落盘。二者不可混用，且都要求禁用 Django 默认上传处理器。
- 分片上传必须前后端约定协议：每个 chunk 带
upload_id、chunk_index、total_chunks，服务端按序写入临时目录，最后合并并校验md5或sha256 - 裸读
request.body时，必须用iter(lambda: request.body.read(8192), b'')这类方式，不能用request.body.read()—— 后者会试图一次性加载全部内容到内存 - 无论哪种方式，上传完成后的文件校验（大小、哈希、magic bytes）都不能省；线上曾出现因 TCP 重传丢失末尾字节导致文件损坏却无报错的情况
最容易被忽略的点：所有超时参数（Nginx、WSGI、Django）必须形成梯度，且最小的那个决定上限。调高 Django 参数却不改 Nginx，等于在门口修电梯——人根本进不了楼。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
