架构决策：如何合理构造适配前端展示的大型JSON响应结构

结构层优化 #

• 替换动态键为数组结构：原结构中voice1、voice2这类动态命名的键会大幅提升解析逻辑复杂度，也不利于后续扩展。可统一调整为voices数组，每个数组元素新增voiceId字段标识编号，原有sum、items字段保留，示例结构：

{
  "voices": [
    {
      "voiceId": 1,
      "sum": 24000,
      "items": []
    }
  ]
}

• 提取公共冗余字段：从示例可以看到多个item的description、info.Id、info.address、info.images字段完全重复，可将这类全voice通用的公共字段提到voice层级，item仅保留price、date等独有字段，字段重复率高的场景下可直接减少60%以上的无效体积。
• 扁平化嵌套层级：去掉info、images这类非必要的嵌套结构，将字段直接提升到item层级，比如把info.images.icon简化为icon字段，既减少JSON本身的符号体积，也能降低前端取值的遍历成本。

体积与传输优化 #

• 字段名缩写：将长字段名改为短缩写，比如description改为desc、address改为addr，数千行规模下整体体积缩减效果非常明显。
• 省略空值字段：对banner这类可能为null的字段，值为空时直接从JSON中移除，前端判断字段不存在即视为空值即可，无需显式返回null。
• 启用传输压缩：服务端开启gzip或brotli压缩，结构化JSON的压缩率普遍超过90%，8000行的原始JSON压缩后实际传输体积通常不足100KB。

渲染体验优化 #

针对全量明细展示的需求，可配合前端优化避免页面卡顿：

• 采用虚拟滚动：前端不一次性渲染全量数据，仅渲染可视区域内的条目，DOM节点数量可减少90%以上，完全避免大列表渲染卡顿问题。
• 按需加载明细：若voice支持折叠交互，可默认只返回所有voice的汇总sum值，用户点击展开对应voice时再请求该voice下的items明细，无需一次性返回全量明细数据。

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