哈希碰撞无法避免，只能通过降低概率与检测兜底；Rabin-Karp 依赖字符比对确认匹配，推荐 MOD 用 1e9+7 或 998244353、BASE 匹配字符集，须处理负数取模，高可靠场景应采用双哈希。
哈希碰撞不是“避免”，而是“检测后兜底”
Rabin-Karp 本身不承诺零碰撞——它用哈希加速筛选，但最终必须靠字符比对确认匹配。所谓“避免”，实际是降低碰撞概率 + 快速识别并处理假阳性。强行追求零碰撞（比如用大到溢出的模数）反而导致计算不稳定或溢出崩溃。
选对 MOD 和 BASE 是降低碰撞的第一道防线
碰撞概率和 MOD 大小强相关：越大的质数 MOD，冲突越少。但不能只看大，还要兼顾 C++ 整型范围和运算效率：
-
MOD推荐用1000000007（1e9+7）或998244353，都是常用大质数，能装进int或long long，且模运算硬件友好 -
BASE应匹配字符集：ASCII 字符用256，小写字母用26，Unicode 场景需谨慎（建议转 UTF-8 后再用256） - 别用
101这类小质数做MOD——千万级文本下碰撞率明显上升，实测 false positive 可达每千次匹配出现 1–2 次
滚动哈希更新时的负数取模陷阱
C++ 的 % 是向零取整，(a - b) % MOD 可能为负，直接参与后续计算会崩掉哈希链。必须显式校正：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
textHash = (textHash - text[i] * h % MOD + MOD) % MOD; textHash = (textHash * BASE + text[i + m]) % MOD;
- 漏掉
+ MOD再取模，textHash会变负，下一轮乘BASE后结果完全不可信 - 尤其当
text[i] * h接近MOD时，这个错误几乎必现 - 别依赖编译器扩展或
std::modulo——C++20 前没标准支持，手写最稳
真正防撞的终局方案：双哈希
单哈希再优也有理论碰撞可能；生产环境高可靠性场景（如日志敏感词扫描、代码 plagiarism 检测），应直接上双哈希：
立即学习“C++免费学习笔记（深入）”；
- 用两组独立参数：
(BASE1, MOD1)和(BASE2, MOD2)，例如(131, 1000000007)+(137, 998244353) - 同时维护两个哈希值，只有两者都相等才触发字符比对
- 碰撞概率从 ~1/MOD 降到 ~1/(MOD1 × MOD2)，实测亿级子串下 false positive 趋近于 0
- 开销仅多一次乘加和一次取模，远低于额外字符比较的成本
双哈希不是“过度设计”，而是 Rabin-Karp 在真实系统中站住脚的标配——哈希值只是门票，字符比对才是入场券，而双哈希让这张门票极难被伪造。
