因为go要求map键必须支持==和!=比较，而slice、func、map在语言层面被定义为不可比较类型，编译器直接报错，无法绕过。
为什么 map 的键不能是 slice、func 或 map？
因为 Go 要求 map 键必须支持 == 和 != 比较，而 slice、func、map 这三类类型在语言层面被定义为「不可比较」——编译器直接报错，不是运行时限制，没法绕过。
常见错误现象：invalid map key type []string、invalid map key type func()、invalid map key type map[string]int。
- struct 可以作键，但所有字段都必须是可比较类型（比如不能含
[]byte字段） - interface{} 作键时，实际值也必须是可比较类型；如果存了 slice，运行时 panic："
panic: runtime error: comparing uncomparable type []int" - 指针可以作键（地址可比），但要注意：两个不同地址即使指向相同内容，也被视为不同键
struct{} 和 string 哪个更适合作为键？
看场景。空结构体 struct{} 零内存占用，适合做「存在性标记」类键（比如去重集合），但语义弱；string 是最常用、最安全的键类型，底层是只读字节数组 + 长度，天然可比较且高效。
性能影响：string 键的哈希和比较成本随长度线性增长；struct{} 永远是常数时间，但你几乎不会靠它优化性能——除非你真在存上亿个空键。
立即学习“go语言免费学习笔记（深入）”；
本文档主要讲述的是Android 本地数据存储；对于需要跨应用程序执行期间或生命期而维护重要信息的应用程序来说，能够在移动设备上本地存储数据是一种非常关键的功能。作为一名开发人员，您经常需要存储诸如用户首选项或应用程序配置之类的信息。您还必须根据一些特征（比如访问可见性）决定是否需要涉及内部或外部存储器，或者是否需要处理更复杂的、结构化的数据类型。跟随本文学习 Android 数据存储 API，具体来讲就是首选项、SQLite 和内部及外部内存 API。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以
- 别用
string拼接复杂数据当键（如"user:" + id + ":profile"），容易出错且难维护；优先封装成 struct - 如果 struct 字段含
string或基本类型，放心用；含指针或 interface{} 要小心，确保赋的值本身可比较 -
struct{}不能直接 print 出有意义内容，调试时可能困惑
想用 slice 当键？绕不过去，但有替代方案
不能直接用，但可以转成可比较类型。最常用的是转 string（需确定元素顺序固定、无歧义分隔）或转为自定义 struct。
例如，把 []int 转成键：
type IntSliceKey struct {
a, b, c int // 仅适用于已知长度且固定
}
或者用 fmt.Sprintf("%v", slice) —— 不推荐，慢且依赖 fmt 实现细节，不同 Go 版本可能行为不一致。
- 用
bytes.Equal对比两个 slice 内容相等，但不能用于 map 键（因为不可比较） - 如果 slice 是配置项或 ID 列表，考虑用
hash/fnv算哈希值再转uint64当键——但注意哈希碰撞风险，仅适用于非关键业务 - 真正需要「slice 语义唯一性」的场景，通常该换数据结构：用
map[string]struct{}存序列化后的 string，或改用sync.Map+ 外部锁管理逻辑
嵌套 struct 作键时，字段顺序和导出性会影响可比较性吗？
不影响可比较性，只影响是否「合法」。Go 规定：struct 所有字段必须可比较，且字段名大小写（导出性）无关；但字段顺序必须完全一致才被视为同一类型。
例如：type A struct{ X, Y int } 和 type B struct{ Y, X int } 是两个不同类型，哪怕字段名和类型都一样。
- 匿名字段继承可比较性：内嵌的 struct 如果本身可比较，外层也 OK；但如果内嵌了 slice，整个 struct 就不可比较
- 数组长度是类型一部分：
[3]int和[4]int是不同类型，前者可作键，后者也是，但二者互不兼容 - 使用
go vet可提前发现 struct 是否可比较：vet -composites会提示不可比较字段
map[key] = value 时发生。 
