因词频统计需大量随机插入与查找，std::unordered_map平均O(1)快于std::map的O(log n)，实测百万词快2–3倍，但需注意哈希性能、避免重复查找、预分配桶数及用string_view减少拷贝。
为什么不用 std::map 而用 std::unordered_map
因为词频统计本质是大量随机插入 + 查找，std::map 是红黑树，单次操作 O(log n)；std::unordered_map 平均 O(1)，实测在百万级单词下快 2–3 倍。但要注意：它的哈希函数和桶数量直接影响性能，不是“用了就快”。
常见坑：std::string 作 key 时，短字符串可能触发 SSO（小字符串优化），哈希计算快；但若字符串超长或大量重复前缀（如日志中的固定路径前缀），默认哈希可能碰撞增多，拖慢查找。
- 建议预估最大单词数，构造时指定桶数：
std::unordered_map<:string int> freq(65536); - 避免在循环中反复调用
freq[word]++（会触发两次查找）；改用auto it = freq.find(word); if (it != freq.end()) ++it->second; else freq.emplace(word, 1); - 如果单词全为 ASCII 且长度 ≤ 16，可考虑自定义哈希（如 FNV-1a），但多数场景没必要
如何切分大字符串又不拷贝内存
直接用 std::string::find_first_of + std::string::substr 会频繁分配新字符串，对 GB 级文本极易触发大量堆分配，成为瓶颈。
正确做法是用“视图式切分”：只记录每个单词的起始/结束位置（std::string_view），全程不拷贝内容。
- C++17 起，优先用
std::string_view作 key：std::unordered_map<:string_view int>，但注意它不能自动管理生命周期——源字符串必须比 map 活得久 - 切分时跳过空白字符，用两个指针移动：
size_t start = s.find_first_not_of(" \t\n\r", pos);，再找下一个空白，构造std::string_view(s.data() + start, end - start) - 若需兼容 C++14 或担心
string_view生命周期，可用std::string的assign成员函数复用缓冲区：word.assign(s, start, len);，避免每次 new
std::unordered_map::rehash 什么时候悄悄拖慢你
当插入导致负载因子（size / bucket_count）超过 max_load_factor()（默认 1.0）时，rehash 会重建整个哈希表——此时所有迭代器失效，且耗时与当前元素数成正比。对千万级词频，一次 rehash 可能卡住几十毫秒。
- 在开始统计前，用
freq.reserve(expected_word_count)预分配足够桶数，比rehash更轻量 - 预估方法：若原文本约 1000 万字符，平均单词长 5 字符，则单词数 ≈ 200 万；预留 2.5 倍（65536 × 4）较稳妥
- 不要依赖
freq.max_load_factor(0.75)来“更稳”，它只是降低碰撞概率，反而让reserve需求更高
大小写、标点、连字符这些细节怎么处理才不伤性能
词频统计常要忽略大小写，但 std::tolower 逐字符转再构造新字符串，开销巨大。标点同理——别用正则，也别用 std::regex。
- 转换策略：遍历原字符串时，对每个单词片段边扫描边转小写，写入栈数组（如
char buf[256]），再用std::string_view(buf, len)查 map - 标点剥离：只检查首尾字符是否为字母/数字，内部保留（如 "don't"、"C++" 应整体计数）；用
std::isalnum((unsigned char)c)判断，注意传参类型 - 连字符处理：若需求是拆开（如 "state-of-the-art" → 4 个词），用双指针扫描时把连字符当分隔符；若保留（如作为独立术语），就当普通字符
真正难的不是算法，是保证 string_view 生命周期、控制哈希碰撞、避开隐式内存分配——这些地方一松懈，性能就掉回 std::map 级别。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
