为何API返回的JSON常用数组存储键值对而非以ID为顶层键？

你观察到的两种JSON结构确实各有适用场景，数组结构的广泛使用并非只是风格选择，而是有不少实用价值：

数组结构的核心优势 #

• 天然支持有序结果：很多API需要返回按特定规则排序的资源（比如创建时间、热度、优先级），数组在JSON标准里是有序集合，能直接保证返回结果的顺序一致性；而JSON对象的键顺序在ES6之前没有标准约束，即使现在多数实现保留插入顺序，也并非所有场景都能依赖这一点。
• 适配分页与批量操作：分页接口返回的结果天然是数组片段，前端拼接分页数据、进行批量删除/更新时，数组的push、slice、filter等操作更直观；如果用对象结构，分页拼接需要合并键值对，批量操作也要额外处理键的遍历。
• 更好的通用性与兼容性：数组是所有编程语言原生支持的基础集合类型，解析和处理代码无需额外逻辑（比如不需要处理ID作为键时的特殊字符问题——如果ID包含斜杠、空格、特殊符号，作为对象键会引发解析或访问问题）；而对象结构在部分强类型语言里需要映射到字典/哈希表类型，处理成本更高。
• 兼容特殊业务场景：虽然业务上通常要求ID唯一，但数组允许临时返回重复ID的中间数据；而对象的键是唯一的，重复ID会直接覆盖数据，丢失信息。
• 贴合REST资源集合语义：REST架构中，/blocks这类端点代表的是资源集合，数组的“列表”形态更贴合集合的直观语义，符合开发者对资源集合的认知。

ID作为键的对象结构的适用场景 #

这种结构的优势在于O(1)时间复杂度的查找，适合需要频繁根据ID快速定位资源的场景。但这个优势可以通过前端后期处理弥补：比如把数组转成Map或者本地对象缓存，后续查找直接用ID访问，不需要每次循环数组。

总结 #

数组结构的广泛使用是权衡了有序性、兼容性、业务场景适配后的选择，属于更通用的REST API响应设计；而ID作为键的对象结构则是特定场景下的优化方案，并非通用首选。

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