根据RFC 4627第2.2节： 2.2。对象
对象结构表示为一对花括号 包含零个或多个名称/值对（或成员）。名字是 串。每个名称后面都有一个冒号，分隔名称 从价值。单个逗号将值与后续值分开 名称。 对象中的名称应该是唯一的。
但是“应该是独一无二的”符合行业最佳实践吗？大多数JSON编码器/解码器都强制执行“必须是唯一的”。 JSONlint.com强制执行“必须是唯一的”。
例如{“foo”：“value1”，“foo”：“value2”}返回Valid JSON， { “富”：“值2” }
第二个同名，取代了同名的第一个条目。
答案 0 :(得分：2)
对象中的名称应该是唯一的。
Douglas Crockford（作者）said about it：
这是RFC中最大的错误。应该是必须的。
遗憾的是，要修复它已经太晚了。
recent ecma json standard并不需要唯一性，以避免使确认rfc且可能包含重复名称的现有json文档无效。
换句话说，{ "foo":"value1", "foo":"value2" }是一个有效的json，但不建议在新的json文档中使用重复的名称。
不同的解析器可以表现不同（或者可以配置为表现不同）：
答案 1 :(得分：1)
对于好或坏，规范允许使用JSON中的重复名称。
问题是解码器在面对这样的重复时的行为是未定义的。
有些解析器会将这样的JSON拒绝为无效（这是唯一可以说是“错误”的行为）。大多数其他人将返回遇到的最后一个。至少有一个我所知道的（因为我写了:)）将JSON严格地视为独立于任何JavaScript解析规则或执行结果的数据结构，并允许通过包含对象内的序数索引分别访问每个命名值（作为替代）通过密钥名称访问，在这种情况下将返回第一个事件。）
虽然有些人认为解码器应该在构造JSON描述的对象时复制JavaScript解析器和执行环境的行为（也就是说，最后一个命名的值会覆盖任何早期的同名值）事实上，JSON只是一种数据结构标准，虽然受到JavaScript语法的启发和借鉴，但并不要求JavaScript执行或反映此类执行的行为。
因此，RFC和ECMA标准都没有规定解码器在面对重复时必须或甚至应该如何表现，因此除了完全拒绝重复名称的解析器之外，接受重复的各种行为都不能说是 “正确”的一个。
如果您在自己控制的进程之间生成和使用JSON，那么可能很容易找到一个适合您的JSON编码器/解码器并继续使用它。但我会反对它。
这让我想到了底线：
虽然JSON标准允许重复，但它不会要求您使用它们，因此最明智的路径就是避免它们并避免完全创建或遇到问题。 ：）