大文件上传超时主因是默认超时机制未适配GB级传输：requests双阶段超时不涵盖数据发送耗时，需同步调优客户端（stream+分块）、反向代理（client_max_body_size等）及后端（MAX_CONTENT_LENGTH+版本），并采用分片上传+断点续传方案。
大文件上传超时不是代码写错了，而是默认的网络层或应用层超时阈值压根没考虑GB级传输场景。直接调 requests.post() 传 1.2GB 视频，不改任何参数，99%会卡在 ConnectTimeout 或 ReadTimeout 上。
requests 默认超时机制在哪卡住你
requests 的 timeout 参数是双阶段控制：第一个数字是连接超时（建连），第二个是读取超时（等响应）。但注意——它只管“发完请求头+请求体后等服务器回 200”的这段时间，不包含“把几百MB数据一块块塞进 socket”的耗时。也就是说，即使你设了 timeout=(30, 3600)，只要底层 TCP 发送缓冲区慢、网络抖动、服务端接收慢，requests 就会在发数据中途抛 requests.exceptions.ConnectionError: ('Connection aborted.', BrokenPipeError(32, 'Broken pipe'))，根本走不到“等响应”那步。
- HTTP/1.1 协议本身不定义上传进度或分片语义，全靠客户端硬扛；
- Python 默认 socket 发送是阻塞式，且无流控反馈，容易被中间设备（如 Nginx、云 WAF）主动断连；
- Flask 默认
MAX_CONTENT_LENGTH是 16MB，超过直接 413，连超时都轮不到。
必须同步调整的三层超时配置
单点调大 timeout 没用，得从客户端发送、反向代理中转、后端接收三处一起松绑：
-
客户端 requests 层：用
timeout=(30, 7200)（连接 30 秒，读响应 2 小时），但更关键的是加stream=True+ 手动分块发送，避免一次性加载整个文件到内存； -
Nginx / Apache 等反代层：确认
client_max_body_size（Nginx）、Timeout（Apache）已调大，例如 Nginx 中需设client_max_body_size 4G;和proxy_read_timeout 7200;； -
Flask 后端：在
app.config['MAX_CONTENT_LENGTH'] = 4 * 1024 * 1024 * 1024（4GB），同时确保 Werkzeug 版本 ≥ 2.3.0（旧版对大 body 解析有 bug）。
真正稳的方案：别传整文件，改用分片 + 断点续传
所有生产级大文件上传最终都绕不开分片。你不需要重写 WebUploader，只需在 Flask 接口里支持 /upload/chunk 和 /upload/merge 两个端点。WebUploader 会自动按 2MB/片切文件、带 chunk、chunks、md5 参数发请求，Flask 只需做三件事：
立即学习“Python免费学习笔记（深入）”；
- 收到分片后存为临时文件（如
uploads/{user_id}/{file_id}_part_0087），不做任何解析； - 合并接口收到全部分片后，用
cat命令或 Python 的open(..., 'ab')追加写入，不 load 全部到内存； - 每个分片请求单独设置短超时（如
timeout=(10, 30)），失败可重试，不影响整体进度。
这样上传 5GB 文件，实际每次 HTTP 请求只传 2MB，超时风险归零，还能暂停、续传、校验 MD5。
容易被忽略的底层坑：TCP 缓冲区与 Keep-Alive
即使逻辑没问题，Linux 内核的 TCP 栈也可能悄悄杀掉长连接。检查并临时调大：
-
net.ipv4.tcp_keepalive_time = 600（保活探测启动时间，从默认 7200 秒降到 10 分钟）； -
net.core.wmem_max = 26214400（发送缓冲区上限，升到 25MB，避免 send() 阻塞）； - Flask 启动时加
--no-reload --workers=1（避免多进程下 socket 复制异常）。
这些不是“优化”，而是让 TCP 能老老实实把你的大文件推完的基本条件。没调它们，光改 Python 代码，只是在给定时炸弹换外壳。
