json.Unmarshal自定义类型：Map与Struct/Slice反序列化行为不一致原因

为什么Map键的反序列化需要encoding.TextUnmarshaler #

首先明确JSON规范的核心限制：JSON对象的键必须是字符串类型。Go的encoding/json包在处理map键的反序列化时，逻辑和struct字段、slice元素完全不同：

• 对于struct字段或slice元素，JSON值可以是任意类型（字符串、数字、嵌套对象等），所以直接调用类型实现的json.Unmarshaler接口是合理的——UnmarshalJSON的设计目标就是处理任意JSON值的解析。
• 但对于map键，JSON输入只能是纯字符串内容（比如"A"对应的实际有效内容是A，不带引号），此时encoding/json会优先尝试用encoding.TextUnmarshaler接口解析：因为UnmarshalText的定位就是处理纯文本字符串到目标类型的转换，完全贴合map键的输入场景。

你遇到的问题本质是：自定义类型仅实现了UnmarshalJSON，它处理的是带引号的完整JSON字符串（比如[]byte("\"A\"")），但map键反序列化时传入的是不带引号的原始字符串字节（[]byte("A")），这会导致UnmarshalJSON解析失败。而实现UnmarshalText后，就能直接处理这种纯文本输入，问题自然解决。

为什么Map键处理有特殊的优先级 #

encoding/json对map键的处理优先级（优先TextUnmarshaler，忽略json.Unmarshaler），是由两个接口的设计定位决定的：

1. json.Unmarshaler用于处理任意JSON值，它接收的是完整的JSON语法片段（比如带引号的字符串、数字、甚至嵌套对象的字节流）。
2. encoding.TextUnmarshaler专门用于纯文本格式的转换，它接收的是不带JSON语法标记（比如引号）的原始字节流，刚好匹配map键的输入形式。

因为map键的JSON输入只能是字符串，用更贴合的TextUnmarshaler是更合理的设计——如果强行用UnmarshalJSON，还需要额外处理JSON字符串的引号解析，反而增加不必要的复杂度。

为什么只有Map采用这种处理方式 #

只有map的键存在JSON类型限制：JSON中仅对象的键必须是字符串，而struct字段、slice元素的JSON值可以是任意类型。对于后两者，json.Unmarshaler能处理更复杂的JSON结构，因此不需要优先使用TextUnmarshaler。

内容的提问来源于stack exchange，提问作者Jason Lui