POST请求传大量数据异常：上传超1万文件时html输入崩溃、URL失效

POST 协议本身完全兼容大容量数据传输场景，HTTP 规范没有对 POST 请求的 body 大小设置硬上限，你遇到的前端崩溃、业务URL无法访问问题，全是前端实现、链路配置、服务端逻辑的缺陷导致的，和POST协议本身无关。

• 前端内存溢出：很多实现拿到<input type="file">选中的FileList后，会循环一次性把所有文件读取到内存（比如转base64、预读计算hash），1万+文件的元数据+读取缓存很容易撑爆浏览器单个标签页的内存上限，直接导致页面崩溃无响应。
• 单请求体积/文件数触发拦截：从CDN、WAF、反向代理（如Nginx）到后端应用服务，全链路各节点默认都有单请求大小限制、单请求表单字段/文件数限制：比如Nginx默认client_max_body_size仅1MB，多数Web框架默认单请求最多接收1000个表单项，超过阈值后节点会直接拒绝请求，配置不当的情况下甚至会触发节点内存异常。
• 服务端OOM导致服务不可用：如果后端代码接收上传文件时，把所有文件全量缓存到内存再处理（而不是流式接收边收边落盘/转存），1万+文件很容易打满服务进程的堆内存，触发进程OOM被系统杀掉，对应业务接口自然无法访问；如果反向代理层开启了全量请求缓存，大请求还可能打满代理节点资源，影响同节点其他业务。
• 浏览器构造请求体阶段崩溃：如果强行把1万+文件塞进同一个multipart/form-data请求，浏览器构造请求分块的过程中会在内存拼接完整请求体，内存占用会直接翻倍，很容易在请求发出去之前就把页面搞崩。

• 前端逻辑优化：不要一次性把所有选中文件读入内存，只维护文件句柄和基础元信息，上传到哪个文件再读取哪个文件的内容；不要单请求塞1万+文件，做限流并发上传，单请求携带10-20个文件即可，大文件单独做分片断点续传。
• 全链路配置排查：逐层检查CDN、WAF、反向代理、后端服务的单请求大小阈值、单请求文件/字段数阈值、请求超时时间，根据业务场景调整合理值，不要无脑把阈值拉到最大。
• 服务端逻辑优化：上传处理用流式逻辑，接收文件数据的同时直接写入临时存储/对象存储，不要等全量文件接收完再在内存里做处理；上传服务单独做资源隔离，避免上传请求的资源占用影响核心业务接口。

不要轻信"POST天生适合传大文件"的说法，HTTP协议层没有传输容量限制，所有容量瓶颈都是实现层自己加的，超大批量文件上传从架构上就应该避免单请求承载全量数据。

内容的提问来源于stack exchange，提问作者Nikita