
给内容做合规过滤，最常见的写法是把词表拼成正则，或者 `foreach` 一遍 `Contains`。词表小的时候都能跑，词表涨到一万条就完全不是一回事了。

本文用 1 万条中文词表、100 万汉字语料，把四种实现放在同一台机器上跑完，所有数字都是本机实测（.NET 10.0.5 / Apple M4 / macOS arm64 / Release / 单线程）。

## 实测结论

| 实现 | 扫 100 万字 | 吞吐 | 建索引 | 索引内存 |
| --- | --- | --- | --- | --- |
| 正则交替（1 万条，解释执行） | 11.6~13.1 s | 0.08 M字/s | 36~38 ms | — |
| 逐词 `Contains` × 1 万 | 0.59~0.62 s（推算） | 1.7 M字/s | 0 | 0 |
| AC 字典树 goto | 28.7~29.9 ms | 33~35 M字/s | 4.1~5.1 ms | 7.68 MB |
| AC 压平边 + 二分查找 | 39.0~39.6 ms | 25 M字/s | 0.7~0.8 ms | 0.68 MB |
| AC 压平边 + 首层直索 | 10.9~11.2 ms | 89~92 M字/s | 0.7~0.8 ms | 0.76 MB |

三句话：

1. 快的那档不是"字典树"，是"压平 + 首层直接索引"。字典树 29 ms，压平后反而掉到 39 ms，加一张 84KB 的直索表才到 11 ms。
2. 相对逐词 `Contains` 是 54 倍，相对 1 万条正则交替是 1060 倍。
3. `Contains` 和正则的耗时与词表条数是线性的，AC 的扫描耗时与词表条数基本无关（只受 fail 链深度影响）。

## 测试方法（可复现）

词表：10,000 条，长度 2~6 字，均长 3.37，从 1,500 个汉字的字池里确定性生成，首字去重 1,497 个。建完是 25,186 个节点、25,185 条边、10,015 个输出（词条 + fail 继承）。

语料：1,000 篇 × 1,000 汉字 = 1,000,000 字（UTF-16 1.91 MB）。每 200 字植入一条真实词条，全库共 6,287 次命中（0.63% 密度）。

计时：`Stopwatch` 手工计时，每项先空跑两次预热，取多轮中位数。

两个口径要说清：

- `Contains` 和正则跑不完 100 万字，实测的是 1 万字（10 篇）和 1 千字（1 篇），表里的 0.6 s / 12 s 是按线性关系推算的，标了"推算"。
- 1 万条交替的正则用解释执行。`RegexOptions.Compiled` 在万条量级构建时间不可控，没纳入这一项；200 条量级的编译版单独测了一组。

## 为什么"压平"反而更慢

这棵树 25,186 个节点，边总数 25,185——平均每个节点只有 1 条边。所以每次 goto 的真实动作是"找一个唯一的子节点"，而不是"在几十个子里挑一个"。

问题在根节点：首字去重 1,497 个，根有 1,497 条边。

扫描 100 万汉字时，绝大多数字符都不可能延续当前前缀，于是都要回根查一次。字典版一次哈希 + 一次探测；压平 + 二分要 11 次数组探测（log2 1497 ≈ 10.5）。所以压平后从 29 ms 掉到 39 ms。

改法很简单：根的边单独做成一张直接索引表。

```csharp
// 根节点直索：char 减去 0x4E00 直接落数组下标
private const int RootBase = 0x4E00;
private const int RootSize = 0xA000 - 0x4E00;   // 20,992 个 int = 84 KB
private readonly int[]? _root;

private int RootLookup(char ch)
{
    int idx = ch - RootBase;
    return (uint)idx < (uint)RootSize ? _root![idx] : -1;
}
```

一次数组访问替代 11 次探测，11 ms 到手，内存只多了 84KB（0.68 → 0.76 MB）。

真正的双数组 trie 是把 base/check 两个数组铺开、用 `base[s] + c` 定位子节点。它省的是"每个节点一份字典头"的开销，在 ASCII 字母表、节点多的时候很划算；但中文首层扇出到 1,497，直接索引更简单、也更快。所以这里没上双数组，用的是"排序边数组 + 首层直索"，效果等价且不用处理基址搜索。

## AC 的扫描速度会随词表变大而下降

同一份语料，只改词表条数（字典版 AC）：

| 词表 | 建索引 | 内存 | 扫描 | 吞吐 |
| --- | --- | --- | --- | --- |
| 100 | 0.05 ms | 0.11 MB | 7.9 ms | 126 M字/s |
| 1,000 | 0.19 ms | 0.92 MB | 16.1~16.6 ms | 60~62 M字/s |
| 10,000 | 4.0~4.3 ms | 7.68 MB | 24.9~26.4 ms | 38~40 M字/s |
| 40,000 | 23.1~26.4 ms | 52.6 MB | 28.2 ms | 35 M字/s |

建索引和内存是线性的（约 1.3 KB/词条，含字典头开销），扫描不是常数：126 → 35 M字/s，掉了 3.6 倍。

原因有两个，都是结构性的：词表越大，前缀路径越深，落到"需要沿 fail 链回退"的字符越多；同时每个节点的输出继承列表变长（10k 词表时输出项 10,015，fail 继承占了一部分）。

结论：AC 的"与词表无关"只在建索引上成立，扫描还是要付 fail 链的账。词表从 1 千涨到 4 万，扫描慢约 2 倍，但仍然是毫秒级，可接受。

## 逐词 Contains 和正则的墙在哪

`Contains` 的耗时完全线性：100 / 1,000 / 10,000 / 40,000 条词表对应 6 / 61 / 593~619 / 2,397~2,434 µs 每千字。每 10 倍词表就是 10 倍时间，没有优化空间。

`IndexOf` 本身不慢——SIMD 实现，在 1 万字文本里找一个 3 字词大约 0.06 µs。问题是要调用 10,000 次。单次很快 × 一万次 = 0.6 毫秒每千字。

正则交替的墙更早：1 万条交替，扫 1 千字要 11.6~13.1 ms，构建本身 36~38 ms。交替是顺序尝试，每个位置都要从第一条试到最后一条，实际是 O(词表 × 文本)。

但正则在 200 条量级完全能用：200 条编译版 27~28 µs 每千字（0.03 s/百万字），只比 AC 慢约 3 倍。所以"正则不能做敏感词"这句话要加定语——千条以下没问题，万条以上才崩。

## 单条 100 字评论的账

把语料截成 200 条 100 字的短文本（弹幕/评论场景），1 万条词表：

| 实现 | 单条耗时 | 折算 |
| --- | --- | --- |
| AC 压平 + 首层直索 | 2.54~2.56 µs | 约 39 万条/秒 |
| AC 字典树 goto | 3.86~4.03 µs | 约 25 万条/秒 |
| 逐词 Contains | 86.0~86.7 µs | 约 1.16 万条/秒 |

短文本下单条调用的固定开销被放大：AC 的 2.5 µs 里，100 字扫描只占一部分，剩下是方法调用与数组首访问。而 `Contains` 的 86 µs 里几乎全是那 10,000 次 `IndexOf` 的调用开销——文本只有 100 字，每次调用几乎立刻返回。

## 正确性对账

快不能靠少匹配换来。10 篇文本上：

- AC 命中的词条集合 66 条，逐词 `Contains` 也是 66 条，集合差 0。
- 出现次数（含重叠）：AC 67 次，正则 `NextMatch` 67 次。

AC 的输出继承是"每个节点带上 fail 链上所有词条"，所以同一位置上的重叠命中会各算一次，不会漏。

## 落地清单

1. **500 条以下**：直接用编译正则。200 条时 27 µs/千字，够用，别为它引入自动机。
2. **1,000 条以上**：上 AC，但边一定要压平——`edgeChar` / `edgeNext` / `edgeStart` / `edgeCount` 四个数组，输出走 `outStart` / `outCount`。每节点一个 `List<int>` 是内存的主要来源（7.68 MB vs 0.68 MB）。
3. **首层单独做直索表**：`char - 0x4E00` 落数组下标，越界落回二分。这一步是 39 ms → 11 ms 的全部原因。
4. **索引只建一次**：热路径 `Scan` 返回命中次数（`long`），不要再构造 `List<Match>`；要具体词条时走单独的慢路径。
5. **AC 只解决精确子串**。插入符（`敏*感*词`）、全角/异体字、拼音变体都得在归一化层处理，这部分成本没有算在本文任何数字里。

## 复现步骤

```bash
cd lab/AhoCorasickLab
dotnet run -c Release
```

工程只有 `csproj` + `Program.cs`，零 NuGet 依赖。词表和语料都用固定 seed 生成，换机器只需看相对倍数；两轮偏差除正则一项（11.6~13.1 ms，12%）外都在 6% 以内，所以表里给的是区间。

## 一句话

1 万条敏感词、100 万字：正则 12 秒，逐词 `Contains` 0.6 秒，AC 字典树 29 毫秒，AC 压平加首层直索 11 毫秒——最后那 2.7 倍速度和 10 倍内存的差别，全在"根节点有 1,497 条边"这一个细节上。


给内容做合规过滤，最常见的写法是把词表拼成正则，或者 foreach 一遍 Contains。词表小的时候都能跑，词表涨到一万条就完全不是一回事了。

敏感词过滤实测：1 万条词表扫 100 万字，正则 12 秒、逐词 Contains 0.6 秒、Aho-Corasick 11 毫秒

算法

后端

编程语言

基于1万条中文词表和100万汉字语料实测，压平边加首层直索的AC自动机最快，扫描吞吐达89-92M字/秒，仅需11毫秒，内存0.76MB。相比逐词Contains快54倍，比1万条正则交替快1060倍。根节点直索表是关键优化，增加84KB内存使速度提升2.7倍。扫描耗时随词表增长略有下降，但保持毫秒级。

代码解释

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

敏感词过滤实测：1 万条词表扫 100 万字，正则 12 秒、逐词 Contains 0.6 秒、Aho-Corasick 11 毫秒-腾讯云开发者社区-腾讯云

敏感词过滤实测：1 万条词表扫 100 万字，正则 12 秒、逐词 Contains 0.6 秒、Aho-Corasick 11 毫秒

敏感词过滤实测：1 万条词表扫 100 万字，正则 12 秒、逐词 Contains 0.6 秒、Aho-Corasick 11 毫秒

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐