go map的key必须支持==和!=比较，不可用slice、map、func等不可比较类型；可比较类型包括int、string、bool、pointer、固定长度数组及所有字段均可比较的struct。
Go map 的 key 必须支持 == 和 != 比较
这是最常被忽略的硬性限制：Go 不允许用 slice、map、func 作 map 的 key，因为它们不可比较。编译器会直接报错 invalid map key type。
可比较类型包括：int、string、bool、struct（所有字段都可比较）、pointer、array（长度固定且元素可比较）。比如 [3]int 可以，但 []int 不行。
常见踩坑点：
- 误把 struct 中嵌套了 slice 当成合法 key，实际会编译失败
- 用 interface{} 作 key 时，若底层值是不可比较类型（如
[]byte），运行时 panic，错误信息为panic: runtime error: hash of unhashable type - 自定义 struct 作 key 前，务必确认每个字段都满足可比较要求，否则 map 操作可能在运行时崩溃
哈希算法不暴露给用户，但影响 key 设计
Go 的 map 底层用的是自研哈希函数（非标准 MurmurHash 或 FNV），对不同 key 类型有专用实现，比如 string 和 int 的哈希路径完全不同。你无法控制或替换它，也不该试图“优化哈希分布”。
这意味着：
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 不要手动对 key 做预哈希（比如传
sha256.Sum256作为 key），这反而增加开销且无收益 -
string类型 key 的哈希计算成本与长度正相关，超长字符串（如几 MB 的 JSON）作 key 会明显拖慢 map 操作 - 结构体 key 的哈希值由所有字段联合计算得出，字段顺序变化（哪怕只是重排 struct 字段）会导致哈希结果不同 → 同样数据可能被存到不同 bucket
map 扩容时 key 的重新哈希不可避免
Go map 扩容不是简单复制，而是对所有已有 key 重新计算哈希值并分配到新 bucket 数组中。这意味着：
- 扩容过程会暂停写操作（但读仍可并发），大量 key 时可能引发短暂卡顿
- key 类型越复杂（比如大 struct 或长 string），重新哈希耗时越长
- 如果 map 在高频写入场景中频繁扩容（例如初始容量太小），建议用
make(map[T]U, n)预估大小，避免多次 rehash
注意：预估容量只影响初始 bucket 数量，不影响 key 的哈希逻辑 —— 它始终由类型决定，跟容量无关。
nil map 与空 map 的行为差异容易混淆
var m map[string]int 是 nil map；m := make(map[string]int) 是空 map。两者 len 都为 0，但关键区别在于：
- nil map 上调用
delete(m, k)安全，不 panic - nil map 上执行
m[k] = v或v := m[k]会 panic，错误是assignment to entry in nil map - 空 map 可安全读写，但底层 bucket 数组尚未分配（首次写入才分配）
这个差异常出现在初始化逻辑里：忘记用 make 就直接赋值，程序跑几轮后突然崩在某个 key 赋值处，而日志里只看到 panic，没提示哪行漏了 make。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
