rabin-karp在超大字符串中易爆int64或哈希冲突，因未取模导致溢出和负数；需用大质数模数（如1000000007）、显式取模、预计算幂次；避免切片拷贝，用mmap/unsafe.slice零拷贝；多pattern须等长且共用哈希查map；文件扫描需处理换行符与边界。
为什么 Rabin-Karp 在超大字符串里容易爆 int64 或哈希冲突？
直接用 int64 累加幂次哈希，窗口一滑动就溢出；更糟的是，Go 默认没做模运算防护，hash = hash * base + byte 几轮后就变成负数或零值，匹配立刻失效。这不是 bug，是没设模数的必然结果。
实际场景中（比如扫描 GB 级日志找 pattern），必须选一个大质数模数，比如 mod = 1000000007 或 mod = 1000000009，且所有加、乘、减操作都得显式取模。别信“uint64 自动绕回”——Rabin-Karp 依赖的是数学同余，不是硬件溢出行为。
-
base建议取 256 或 257（避开 256 的幂次与 mod 冲突） - 预计算
pow = pow(base, windowLen-1, mod)，用于滑窗时快速删首字符 - 每次
hash = (hash - (s[i] * pow) % mod + mod) % mod—— 注意加mod再取模，防负数
如何避免 slice 复制导致内存爆炸？
别对每个窗口做 s[i:i+windowLen] 切片再算哈希。超大字符串（比如 10GB 文件 mmap 后）切片本身不复制数据，但若你拿它去调 sum([]byte) 或喂给其他函数，底层可能触发隐式拷贝。Rabin-Karp 的核心优势就是 O(1) 滚动更新，不该破坏它。
真正要做的，是把输入当作只读字节流处理：用 io.Reader 或 mmap.File + []byte 视图，靠索引移动，只维护当前窗口起始位置和哈希值。
- 用
unsafe.Slice（Go 1.20+）从 mmap 地址构造零拷贝视图，但需确保内存未被释放 - 若用
os.File.Read()分块读，每块末尾预留windowLen-1字节重叠，避免跨块漏匹配 - 绝对不要在循环里写
string(s[i:i+windowLen])—— 这会分配新字符串并拷贝字节
怎样让匹配支持多 pattern 且不降速？
单 pattern 用 Rabin-Karp 很稳；但多个 pattern 时，若对每个 pattern 单独滚动哈希，时间退化成 O(n × m)，完全失去滑窗意义。正确做法是把所有 pattern 哈希值存进 map，一次滚动只算一个主哈希，再查 map 是否命中。
注意：pattern 长度必须一致才能共用同一套滚动逻辑。如果长度不同（比如同时搜 "abc" 和 "xyzw"），要么分组处理，要么改用 Aho-Corasick —— Rabin-Karp 不适合变长模式。
- 预处理：对每个 pattern 计算其哈希值，存入
map[uint64][]int（哈希 → pattern 下标列表） - 滑动时只维护一个哈希，每次更新后查
patternsHashes[hash]，有则记录位置 - 若两个不同 pattern 碰巧哈希相同（冲突），靠后续字节逐个比对确认 —— 这是必要开销，无法避免
文件级扫描时怎么处理边界和换行符？
真实日志或文本文件不是纯字节流：行尾有 \n 或 \r\n，而你的窗口可能横跨两行。Rabin-Karp 本身不关心语义，但如果你的 pattern 是 “ERROR”，而文件里是 “ERR\nOR”，那就永远匹配不上。
解决方案取决于需求：若要求严格连续字节匹配，就按原始字节流处理，无需特殊对待换行符；若 pattern 语义上跨行合法（比如正则中的 [\s\S]*），那得先 normalize 换行符，或改用支持上下文的匹配器。
- 用
bufio.Scanner逐行读时，记得保留行尾符（设置Split(bufio.ScanBytes)或手动拼接） - 若用
mmap，直接按字节索引访问，\n就是0x0a，和其他字节无区别 - 边界 case：窗口落在文件末尾不足
windowLen时，提前 break，别越界读s[i+windowLen]
滚动哈希的陷阱不在算法本身，而在模运算细节、内存视图控制和边界判定——这些地方错一点，整个超大字符串扫描就静默失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
