是否有任何正式的提议在进行中，以解决对JSON当前对Map对象的处理的向后兼容演变？
例如，假设您要将Map转换为JSON，然后将其写入文件：
let map = new Map();
map.set(1, "A");
map.set(2, "B");
map.set(3, "C");
// Convert map to an "array of 2-element arrays":
let arrayFromMap = [... map];
let json = JSON.stringify(arrayFromMap);
writeJSONtoFile(json,"path/to/jsonFile.json");
所以现在磁盘上有一个JSON文件。问题是，最终读取该文件的代码不知道它包含Map对象，除非我们赋予该代码文件这种认识。 JSON中没有固有的内容可以明确地指示Map而不是“ 2元素数组的数组”。例如，不具有此awareness的代码可能会这样做：
let json = readJSONfromFile("path/to/jsonFile.json");
let parsedJSON = JSON.parse(json);
console.log(parsedJSON); // outputs an "array of 2-element arrays"
但是，如果代码编写者提供了代码意识（原始类型是Map，则可以将文件转换回Map：
let json = readJSONfromFile("path/to/jsonFile.json");
let map = new Map(JSON.parse(json));
对于相同的awareness，这些内置对象：对象和数组不是必需的。
在上面的示例中，这种“意识”要求不是很繁重。但是，请想象一个既包含Maps又不包含Maps的“ 2元素数组的数组”的大型层次结构。现在，这种“意识负担”已扩展到层次结构中的each nested Map。
是否有任何正式的提议在进行中，以解决对JSON当前对Map对象的处理的向后兼容演变？
否，因为JSON表示法起源于Javascript，但是它在许多语言中广泛使用，但是Javascript Map仅在Javascript上下文中具有含义。
对JSON表示法进行任何形式的更改以允许对仅在Javascript中具有含义的对象进行序列化和反序列化，将使JSON格式与大多数其他语言不兼容。
这并不是说不能编写基于JSON的自定义解析器来正确地序列化和反序列化地图，但是这样的事情只能是基于JSON，而不是对JSON的补充标准。
[就像SomePerformance的答案，重要的是，为了保持可移植性和兼容性，JSON保持尽可能抽象。
想要补充一点，将Map对象的完整性保持在JSON对象内部确实非常简单，而无需添加新的规范；就像在序列化过程中每个Map添加一个标志。