字符串键高频访问变慢，因每次需计算哈希并可能逐字符比较，二者均与长度正相关；嵌套访问（如nb.modelclass）加剧开销；重复短字符串宜intern或映射为整数ID，并预设map容量以避免扩容抖动。
字符串作为 map 键在高频访问场景下会显著拖慢性能，尤其当键长度不可控、重复率低、或嵌套层级深时——runtime.mapaccess1_faststr 很可能成为 CPU 热点。
为什么 string 键在高频访问时变慢？
Go 的 map 对 string 键每次访问都要做两件事：计算哈希值、冲突时逐字符比较。这两步都和字符串长度正相关。
- 哈希计算需遍历整个
string内容，短键（如"user_123"）尚可，长键（如 JSON 片段、URL 路径）开销陡增 - 哈希冲突后，比较逻辑走的是
memcmp风格的字节比对，不是指针比——哪怕两个string指向同一底层数组，只要内容相同就得比完所有字节 - 在朴素贝叶斯分类器这类场景中，
nb.model[class][term]是三层字符串键嵌套，每层都触发一次哈希+比较，累积效应明显
何时该考虑 intern 字符串？
当你有大量重复出现的短字符串（如状态码 "200"、类别名 "spam"、字段名 "email"），且生命周期贯穿程序运行期，intern 就值得做。
- 用全局
map[string]string做“驻留池”，首次见某字符串就存进去并返回其地址；后续都复用这个地址 - 实际效果是把多次哈希+比较，降为一次指针比较（因为 intern 后的字符串底层数据共用，
==可快速判定） - 注意：不要对用户输入或临时拼接字符串（如
fmt.Sprintf("req_%d", id)）做 intern，容易内存泄漏
替代方案：用整数 ID 代替字符串键
如果业务允许，把高频字符串映射为 int 或 uint64 是最直接的加速方式。
立即学习“go语言免费学习笔记（深入）”；
- 预加载阶段扫描全部可能的字符串键，分配唯一 ID，构建
map[string]uint64（只建一次） - 主逻辑中用
uint64当 map 键：map[uint64]float64，哈希计算几乎无开销，比较是单指令 - 代价是需要维护字符串 ↔ ID 的双向映射，且无法动态增删键类型（除非加锁重build）
容易被忽略的细节
即使你用了 intern 或 ID 映射，如果 map 本身没预设容量，初始化时仍会频繁扩容，导致桶数组反复复制——这对高频写入路径影响极大。
- 比如预估有 5000 个唯一类别名，就该写
make(map[uint64]float64, 5000)，而不是make(map[uint64]float64) - 嵌套 map 如
map[string]map[string]float64，外层和内层都得预设容量，否则内层每次nb.model[class] = make(map[string]float64, 100)也会抖动 - 别忘了并发安全：高频读写下，标准 map 不加锁会 panic；
sync.Map适合读多写少，但写路径更重，真高并发建议分 shard
