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