大数据量JSON序列化不增加通信延迟但延长准备发送时间，优化需聚焦减小体积、分块处理、非阻塞主线程及流式传输；压缩、流式解析、二进制替代和避免反模式是关键手段。
大数据量 JSON 序列化本身不直接增加通信延迟，但会显著拉长“准备发送”的时间，造成端到端响应变慢。真正影响通信延迟的是序列化耗时、传输体积、以及前后端处理节奏的错配——优化重点应放在减小数据体积、分块处理、避免阻塞主线程和合理使用流式传输上。
压缩数据体积：减少序列化与传输开销
JSON 默认是纯文本，未压缩时体积大、解析慢。尤其当包含大量重复字段（如日志列表中的 timestamp、level）、冗余嵌套或 base64 图片时，体积激增明显。
- 用短字段名替代长语义名（如
ts替timestamp），配合前后端约定字典，可降低 20%~40% 体积 - 服务端启用 Gzip/Brotli 压缩（HTTP 响应头
Content-Encoding: br），对文本类 JSON 效果极佳，通常压缩率 70%+，浏览器自动解压无额外开发成本 - 避免在 JSON 中内联大二进制数据；改用 URL 引用 + 单独资源请求，让浏览器并行加载、缓存复用
分块序列化与流式传输：避免内存与响应阻塞
一次性 JSON.stringify(largeArray) 可能导致 JS 主线程卡顿数秒，用户感知为“页面假死”，且服务端需等全部数据就绪才开始发包。
- 后端采用流式 JSON 库（如 Node.js 的
json-stream-stringify或 Python 的ijson）边查库边写响应，实现“查询即传输” - 前端用
ReadableStream+TextDecoder分段读取响应体，配合JSON.parse()或JSONStream解析，无需等待整个响应结束 - 对列表类数据，按页或按批次返回（如每次 100 条），配合游标（
cursor）而非偏移量（offset），提升服务端查询效率
替代序列化方案：绕过 JSON 性能瓶颈
当数据结构高度固定、性能要求极致（如实时仪表盘、IoT 数据推送），可考虑非 JSON 格式降低解析开销。
立即学习“前端免费学习笔记（深入）”；
- 使用 Protocol Buffers（protobuf） 或 Apache Arrow：二进制格式，体积更小、解析更快；需前后端共用 schema，通过工具生成 JS 绑定代码
- 前端用
ArrayBuffer+DataView直接解析二进制流，避开字符串解析和 GC 压力，适合数值密集型数据（如传感器时间序列） - 对只读展示场景，服务端渲染 HTML 片段（如
text/html流）或使用template+innerHTML批量插入，比 JSON → Virtual DOM → render 更快
避免常见反模式：小改动带来大收益
很多延迟问题其实源于设计惯性，而非技术瓶颈。
- 禁用
JSON.stringify(obj, null, 2)（带缩进）用于生产环境响应——美化格式会使体积膨胀 2–3 倍，且无实际业务价值 - 不把整个数据库记录全量返回；用 GraphQL 或 JSON:API 规范按需选字段（
fields=id,name,updated_at），服务端精准投影 - 前端收到大数据后，别立刻
setState([...old, ...new])；改用虚拟滚动（如react-window）或惰性加载，保持 UI 响应性
