rabin-karp哈希易溢出因幂次累加导致整数溢出，须用双模或随机基配合预计算power数组；string_view可安全使用但需确保数据生命周期；哈希相等后仍需逐字符比对以防碰撞；滚动更新优于前缀和。
为什么 RabinKarp 的哈希值容易溢出？
因为滚动哈希依赖幂次累加，比如对字符串 s[0..n-1] 计算 hash = s[0]*p^(n-1) + s[1]*p^(n-2) + ... + s[n-1]，p 通常取 31 或 101，指数一高，long long 都扛不住。不处理就直接 overflow，结果全错。
- 必须用模运算控制范围，但模数不能随便选：太小（如
1e9+7）在长文本中冲突率飙升；太大（如2^64）又没法用unsigned long long自动溢出模拟（GCC 支持，但 Clang/MSVC 行为不一致） - 推荐组合模：双模（如
1000000007和1000000009）或单模 + 随机基（p在运行时随机生成），能显著压低误匹配概率 - 滚动更新时别手写
pow(p, len)—— 预先算好power[len]数组，否则每次O(len)滚动退化成O(n*len)
std::string_view 能否直接用于 RabinKarp 滚动？
可以，而且应该用。它避免构造临时 std::string，尤其在频繁切片（如滑动窗口）时，内存和拷贝开销直接省掉。
- 注意
string_view.data()返回的指针生命周期必须长于哈希计算过程 —— 如果传入的是局部std::string的substr()结果，而该string在函数返回后析构，data()就悬空了 - 安全做法：把待查文本存为持久对象（如类成员或全局
const std::string&），再用string_view切；或者干脆传const char*+size_t len，更底层也更可控 - 别对
string_view调用.c_str()—— 它不保证结尾有\0，且可能触发隐式转换开销
匹配失败时，为什么 hash == pattern_hash 还要逐字符比对？
哈希碰撞无法彻底避免，哪怕用了双模。Rabin-Karp 是「筛选器」，不是「判决器」。
- 只靠哈希相等就返回位置，遇到构造性对抗数据（比如大量前缀相同的字符串）会漏判或误判
- 逐字符比较成本其实很低：平均只比 1–2 个字符就发现不等（英文文本下 ASCII 分布足够散）；最坏才是
O(len)，但那是极小概率事件 - 如果业务允许一定误报（比如布隆过滤场景），可跳过比对，但标准字符串匹配必须做 —— C++ 标准库的
std::search也没跳
用 std::vector<unsigned long></unsigned> 存哈希前缀和，真比每次滚动快吗？
不一定。前缀和适合「任意区间哈希查询」，但 Rabin-Karp 匹配只需要固定长度窗口滚动 —— 此时前缀和反而多占内存、多一次减法、还要预处理整个文本，得不偿失。
立即学习“C++免费学习笔记（深入）”；
- 滚动更新公式更简单：
hash = (hash - s[i] * power[len-1]) * p + s[i+len]，一行搞定，O(1)时间 - 前缀和需要额外
O(n)空间存hash_prefix[i]，还得多维护一个power数组，代码更重 - 只有当你需要支持「查询任意子串哈希」（比如多次不同长度模式匹配），才值得上前缀和 +
power逆元
真正容易被忽略的是：power[len-1] 这一项必须提前缓存，千万别在循环里反复调用 std::pow —— 它是浮点函数，精度崩、速度慢、还不支持整数模运算。
