用static代码块在类加载时构建trie前缀树可实现启动即就绪的o(m)文本过滤，关键在于树结构设计与初始化时机；须避免i/o、使用精简节点、支持最大匹配与重叠覆盖，并监控gc压力。
用 static 代码块在类加载时构建敏感词前缀树（Trie），能实现启动即就绪、无延迟的文本过滤。关键不在“static”本身，而在它触发的初始化时机和树结构设计是否真正支持 O(m) 单次匹配（m 为文本长度）。
敏感词树必须用 Trie，不能用 List 或 Set
把敏感词存进 ArrayList 或 HashSet，再逐个匹配——这是常见误区。哪怕用 contains()，对每个词都要做完整字符串比对，10 万词 + 1KB 文本 = 百万级比对，根本做不到秒级。
- Trie 树让匹配过程变成“按字符跳转”，最多遍历一遍文本就能完成所有词检测
- 每个节点只存一个字符，子节点用 Map
或固定大小数组（如 ASCII 可用 128 长度数组） - 标记 isEnd 表示此处为敏感词结尾，并可附带词频、替换规则等元信息
static 块里只做不可变树构建，不碰 I/O 和外部依赖
static 块执行在类首次主动使用时（如调用静态方法或访问静态字段），适合加载只读数据。但若在里面读文件、连数据库或调远程接口，会拖慢启动、引发异常阻塞类加载。
- 敏感词源建议打包进 jar（如 resources/keywords.txt），用 ClassLoader.getResourceAsStream 读取
- 读取后立即解析成 Trie，过程中不做任何日志输出、网络请求、锁操作
- 构建完成后，将 root 节点赋给 static final Node ROOT，确保线程安全且不可修改
过滤逻辑要支持“最短/最长匹配”与“重叠覆盖”
单纯走 Trie 找到就停，会漏掉嵌套词（如“苹果”和“苹果手机”）。实际需结合滑动指针 + 回溯或 BFS 拓展，才能兼顾效率和覆盖率。
- 推荐用“最大匹配”：从当前位置出发，尽可能往下走到最深的 isEnd 节点，记录最长命中词
- 命中后跳过对应长度，继续下一段；也可选择“全部匹配”，用 List 收集所有命中位置
- 替换时注意避免重复处理，例如“南京市长江大桥”中“南京”“南京市”“长江”“大桥”都可能命中，需按起始位置+长度排序去重
上线前必须验证树规模与 GC 压力
10 万词的 Trie，节点数通常在 20–50 万之间（取决于词重叠度）。看似不大，但如果每个节点含 Map 和额外字段，容易引发 Minor GC 频繁，尤其在低配机器上。
- 用 jmap -histo 或 JProfiler 查看 Trie Node 实例数量和内存占比
- 节点尽量精简：只保留 children 数组/Map + isEnd +（可选）wordId，避免 String 引用或复杂对象
- 启动日志打印“加载 X 个敏感词，生成 Y 个 Trie 节点”，作为容量基线供运维监控
