replaceall不能直接用正则匹配敏感词，因敏感词含.、*、+等元字符未转义会抛patternsyntaxexception；需用pattern.quote转义，但大词库拼长正则易致编译慢、回溯风险高；中等规模宜用indexof逐个替换更稳。
replaceAll 为什么不能直接用正则匹配敏感词
因为 replaceAll 第一个参数是正则表达式，而敏感词里可能含 .、*、+、( 等元字符，不转义会误匹配甚至抛 PatternSyntaxException。比如词库含 “C++” 或 “a.b”，直接传入 "C++".replaceAll("C++", "***") 就会报错。
常见错误现象：java.util.regex.PatternSyntaxException: Dangling meta character '+'
- 必须对每个敏感词调用
Pattern.quote(word)转义后再拼进正则 - 如果词库大（比如上千词），拼成一个超长正则（
Pattern.compile("word1|word2|word3|...")）会导致编译慢、内存高、回溯风险大 - Java 8+ 的
String.replaceAll底层仍走Pattern，没跳过正则引擎
遍历词库 + indexOf 比 replaceAll 更稳的场景
当敏感词数量中等（几十到几百）、且不需要“词边界”控制（如“色”不匹配“颜色”）时，逐个扫描替换更可控、更易调试。
使用场景：后台审核日志、内部表单提交前轻量过滤、非高并发文本清洗
- 用
StringBuilder接收结果，避免频繁创建String - 每次调用
str.indexOf(word, start)查找，找到就替换并跳过已处理位置，防止重叠词重复处理（如“法轮功”含“功”，但不应再单独替“功”） - 注意大小写：若需忽略大小写，
indexOf不支持，得改用str.toLowerCase().indexOf(word.toLowerCase())，但要同步维护原始偏移——更稳妥是预处理词库全小写，原字符串也小写查，替换时仍用原词长度占位
屏蔽词库加载和缓存的实际取舍
词库通常存在文件或 DB，但每次替换都读一次文件？显然不行。关键是「什么时候加载」「怎么热更新」。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
常见错误现象：词库更新后服务不重启就无效；多线程并发修改 List 导致 ConcurrentModificationException
- 启动时用
Files.readAllLines(Paths.get("sensitive-words.txt"))加载，存为CopyOnWriteArrayList<string></string>或volatile List<string></string> - 避免用
static final List—— 无法热更新 - 如果词库超 500 行，考虑构建
Trie树（如com.github.kstyrc:trie），但小项目没必要，徒增依赖 - 别把词库放
application.properties里用逗号拼——难维护、易出格式错
replace vs replaceAll：简单字面替换别绕弯
如果确定所有敏感词都不含正则元字符，且不需要全局正则能力，直接用 String.replace(CharSequence, CharSequence)，它做的是字面量替换，不走正则引擎，更快更安全。
性能影响：在 JDK 9+，replace 是 StringLatin1.replace 内部优化过的，比 replaceAll 快 2–3 倍（尤其短文本）
-
"hello world".replace("world", "**")✅ 安全、快 -
"hello world".replaceAll("world", "**")⚠️ 多一层正则编译，没必要 - 但
replace不支持正则功能（比如替换所有数字串），这时候才考虑replaceAll+Pattern.quote
真正麻烦的不是替换逻辑本身，而是词库更新时机、大小写策略、重叠词顺序、以及要不要支持通配符（比如“*毒*”）。这些一旦定下来，就很难在不停服情况下改。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
