其实我经常调侃我们后端是服务端，服务端嘛，当然是给前端服务的，前端要啥，我们就给啥，前端怎么好处理，我们就怎么给。具体到这个问题，提问者给出的样式感觉是有问题的，后端多半是给了个字典。就具体的例子里面，直接以字典映射为JSON的对象并不一定都是错的，主要还是两边多沟通，取得最好的方案。

毕竟字典对于前端用for in也能遍历出来，除了丢了顺序。如果这个数据结构本来就是个字典，例如产品属性，你非要搞成[{"name": "width"，"value": 100},...]显然是没有必要，当然属性顺序需要保证的时候也就不得不写成这样了……我说现在为啥很多前端都用node.js去写个中间层了，原来现在后端都是这样写程序的那也不难理解了。

所以我一向建议大家不要歧视调库程序员，这种问题只要调库调得多，根本就不是问题。比方说，假如你调过gson库，或者说你调过许多json解析库，就会知道，json接口如果定义成某些形态，是无法直接反射到数据对象的。

假如你调库调得多，你就会明白，定义一个json接口的时候尽量保证这个接口能够直接对应到目标语言的数据结构的json数据，会用起来更方便。这样，你就会不知不觉中把json接口定义成能够直接映射为数据结构的格式。也就不知不觉中，习惯定义成题主所说的第一种形态。而不需要知道为什么。

题目中的后端程序员，如果直接拿一个数据结构映射到json的库去输出，大概是不会返回成这个样子，毕竟，一个数组里边每一个object都具备不同的key，这种写法不符合常规json库的实现思路。那么我对这个问题的看法就很简单：第二种格式是无法用gson解析的，也是无法直接映射到编程语言数据结构的。而第一种就可以。那么我就会建议选第一种。

对接过一个奇葩数据；[{'技术部'：'郭靖'}，{'技术部1'：'郭靖1'}，{'技术部2'：'郭靖2'}]类似这种数据格式，我当时震惊了，在这个年代，后端能写出这种格式的数据，也是有江湖地位的咖位。作为新兴前端的我，觉得这种数据是不能用的，如果非要较真，那么我可以处理完去使用，但是这样返回数据，浏览器直接就报错了，不带编译的。

和后端去说，人家就说在老系统就这样；不能多问，问了就是老系统就这样。