如何解决React向Django REST API传100MB以上JSON时浏览器卡顿问题

100MB以上JSON传输卡顿/卡死的核心原因是：前端全量序列化超大JSON时占用浏览器主线程导致UI阻塞，全量加载数据引发浏览器内存飙升；后端默认请求大小限制拦截请求，全量解析大JSON占用过多服务端资源。

React端适配调整 #

• 分片传输：把大JSON拆成多个10-20MB的小块，给每个块添加序号、总块数、唯一传输ID标识，分批发送，所有块传输完成后通知后端合并。避免单次序列化超大对象占用主线程，同时支持断点续传能力。
• 非阻塞序列化：不要直接调用JSON.stringify()处理100MB以上的对象，可使用Web Worker在后台线程处理序列化逻辑，不占用页面主线程，避免UI卡顿无响应。
• 开启传输压缩：传输前用pako等工具库把JSON内容压缩为gzip格式，请求头添加Content-Encoding: gzip，通常可把JSON体积压缩到原大小的1/5-1/10，大幅降低传输负载和序列化开销。
• 流式处理数据：如果数据来源于本地JSON文件，不要用FileReader一次性读取全量文件内容到内存，改用流式读取接口逐块处理，避免浏览器内存溢出。
• 调整请求配置：使用fetch或axios发起请求时，关闭默认的超时限制，或把超时时间调整到足够大的阈值，避免大体积数据传输中途被中断。

Django REST API端适配调整 #

• 调大请求体上限：Django默认的DATA_UPLOAD_MAX_MEMORY_SIZE配置为2.5MB，需要在settings.py中调整到大于最大传输体积的阈值，示例配置：DATA_UPLOAD_MAX_MEMORY_SIZE = 200 * 1024 * 1024。如果使用Nginx做反向代理，需要同步调整Nginx的client_max_body_size配置为对应大小。
• 实现分片接收逻辑：对应前端的分片传输规则，开发分片接收接口，根据传输ID、块序号暂存收到的分片数据，所有块接收完成后再合并为完整的JSON内容做后续处理。
• 流式解析JSON：不要使用DRF默认的JSONParser全量加载请求体后再解析，替换为ijson等流式JSON解析库，逐块解析JSON内容，无需把100MB以上的完整JSON全量加载到服务端内存，大幅降低服务端内存开销。
• 支持gzip解压：在Django配置中开启GZipMiddleware，或在Nginx层配置自动解压gzip格式的请求体，自动处理前端传输的压缩内容。
• 调整超时阈值：同步调大Django请求超时、uWSGI/Gunicorn等应用服务器的超时时间，避免大请求处理到一半被超时中断。

额外优化建议 #

• 如果业务场景允许，优先不要使用JSON作为大体积数据的传输格式，可替换为CSV、Parquet等更适合大体积结构化数据的格式，体积更小，序列化和反序列化速度更快。
• 如果是本地文件上传场景，直接走文件上传逻辑，不要把文件内容读取为JSON对象后再传输，稳定性更高。

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