AC自动机做全文搜索的核心瓶颈在I/O与内存管理而非匹配逻辑：需用64KB缓冲区循环fread、保留max_pattern_len−1字节滑动尾巴、禁用stdio同步、UTF-8需预处理，fail指针必须BFS构建，output链须链式继承，节点分配宜用预分配池。
直接说结论：用 AC 自动机做文件全文搜索，核心不是“能不能快”，而是“怎么避免在 I/O 和内存上翻车”——90% 的性能瓶颈不在匹配逻辑，而在 fread 方式、缓冲区大小、字符编码边界和 fail 指针构建顺序。
如何把文件流喂给 AC 自动机而不卡死
AC 自动机本身是内存结构，但文件往往远大于内存。不能一次性 fread(buf, 1, SIZE_MAX, fp) 加载整文件（尤其 GB 级日志），也不能逐字节 fgetc 调用（系统调用开销爆炸）。
实操建议：
- 用固定大小的缓冲区（如 64KB）循环
fread，每次读完立即送入 AC 自动机的match函数，不要攒着等 EOF - 缓冲区必须保留至少
max_pattern_len - 1字节的“滑动尾巴”：比如最长模式串是 128 字符，每次读 64KB 后，最后 127 字节要拷贝到下一次读取的开头，否则跨块边界的关键字（如 "error\nat line" 拆在两块）会漏掉 - 避免
std::ifstream默认的同步 I/O（sync_with_stdio(false)必须设，且关闭tie(nullptr)） - 如果文件是 UTF-8，别用
char直接喂——遇到多字节字符（如中文）被截断，会导致fail指针跳转错位；先按字节流处理，或预转为 UTF-32 再进 AC
构建 AC 自动机时最容易崩的三个点
不是算法写错，而是工程细节导致匹配结果不全或 crash：
立即学习“C++免费学习笔记（深入）”；
-
fail指针必须用 BFS（queue）按层构建，不能 DFS：否则子节点的fail可能指向一个还没算好fail的父节点，后续匹配时跳转到未初始化内存 - 输出链（output link）不能只存“本节点是否为结尾”，得链式记录所有后缀匹配：比如插入
"he"和"she"，查"she"时，节点e不仅要报告"she"，还要顺着 output link 报"he"；否则敏感词过滤会漏掉子串关键词 - 对象池分配器若没重载
operator new或没对齐，大量短生命周期节点（尤其小模式集+大文本）容易触发 malloc 频繁调用；用std::vector<ACNode>预分配 + 游标分配更稳
匹配阶段为什么跑不满 CPU
看起来 AC 自动机是纯计算，但实际常被 I/O 或缓存击穿拖慢：
- 模式串太少（strstr；用
std::string_view::find_first_of+unordered_set更轻量 - 缓存不友好：Trie 节点若用
new散落在堆上，children[26]数组每次跳转都 cache miss；改用紧凑数组布局（如vector<ACNode>+ index 替代指针）可提速 2–3 倍 - 没做 SIMD 加速：对 ASCII 模式集，可用
_mm_cmpistri批量比对缓冲区前缀，但注意这会破坏 AC 的通用性，仅限已知字符集场景 - 多线程并行时，别让多个线程共用同一个 AC 自动机实例——
fail指针是只读的，但匹配过程中的状态变量（如当前节点指针）必须 per-thread 维护
文件搜索结果怎么准确定位行号
AC 自动机只返回偏移量，但用户要的是 “第 123 行，第 45 列”。别在匹配后回溯找换行符：
- 预扫描文件，用
mmap+memchr构建行首偏移表（vector<off_t>），O(1) 查第 N 行起始位置 - 匹配时传入当前已读总字节数 + 当前缓冲区内偏移，累加得全局 offset，再二分查行表
- 如果文件带 BOM 或混合换行符（
\r\n/\n），行表必须按实际解析生成，不能简单数\n个数 - 避免用
std::getline边读边匹配——它内部有额外内存分配和字符串构造，吞吐量直接腰斩
真正难的从来不是“怎么写 AC 自动机”，而是“怎么让它在真实文件流里不丢字、不越界、不卡顿、不误报”。尤其是跨块边界匹配、UTF-8 截断、行号映射这三处，调试时几乎看不到明显错误，但结果就是少几条命中——得靠带 offset 的测试用例一条条压。
