因为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语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 别用
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 时发生。 
