replace() 不适合在触发器中做多词敏感词过滤，因其存在顺序依赖、大小写/全角绕过、字段截断、无匹配反馈四大缺陷，且典型错误写法易导致null值、逻辑漏判和性能问题。
不能直接用 REPLACE() 在触发器里做多词、安全、可维护的敏感词过滤。 它看似简单，实则在生产环境极易引发语义错乱、性能卡顿、逻辑漏判甚至触发器报错。
为什么 REPLACE() 不适合敏感词批量替换
触发器中对 NEW.content 反复调用 REPLACE(NEW.content, 'xxx', '***') 是常见但危险的做法：
- 顺序依赖：若词库含“小”和“小明”，先替“小”会导致“小明”变“***明”，再替“小明”就失效
- 大小写/全半角/空格绕过：默认
REPLACE()区分大小写且不处理 Unicode 变体，'Xxx'和'ｘｘｘ'（全角）完全逃逸 - 字段截断风险：TEXT 字段被多次
REPLACE()拼接后可能超长，触发ERROR 1406 (22001): Data too long - 无匹配反馈：
REPLACE()对未命中词返回原字符串，无法判断是否真有敏感词命中，后续打标或日志无依据
BEFORE INSERT 中用 REPLACE() 的典型错误写法
下面这段代码在多数场景下会出问题：
DELIMITER $$ CREATE TRIGGER filter_content_before_insert BEFORE INSERT ON posts FOR EACH ROW BEGIN SELECT word INTO @sw FROM sensitive_words LIMIT 1; SET NEW.content = REPLACE(NEW.content, @sw, '***'); END$$ DELIMITER ;
问题包括：
-
SELECT ... INTO @sw没有WHERE条件，只取任意一个词，无法遍历词库 - 使用用户变量
@sw，跨会话可能残留值，MySQL 8.0.23+ 中行为不稳定 - 没检查
@sw是否为空或 NULL，一旦sensitive_words表为空，@sw为 NULL →REPLACE()返回 NULL → 整个NEW.content变 NULL - 没加
IF EXISTS或计数校验，无法知道是否真命中
如果坚持用 REPLACE()，必须满足这 4 个前提
仅当业务极轻量、词库固定 ≤5 个、且接受语义损失时，才可考虑简化方案。需同时满足：
- 词库必须预处理去重、排序（长词优先），避免嵌套覆盖；例如先替“中华人民共和国”，再替“中国”
- 所有敏感词统一转小写，
NEW.content也提前用LOWER()标准化，否则大小写漏判 - 逐词用
DECLARE v_word VARCHAR(255) DEFAULT '';+SELECT word INTO v_word FROM sensitive_words WHERE ... LIMIT 1;，不用@变量 - 每次
REPLACE()后用CHAR_LENGTH()对比长度变化，确认是否发生真实替换，用于设置NEW.flag_sensitive = 1
真正可控的替代路径：打标代替替换
生产系统中更健壮的做法是放弃在触发器里改内容，改为记录风险信号：
- 用
SELECT COUNT(*) INTO v_hit FROM sensitive_words WHERE LOWER(NEW.content) LIKE CONCAT('%', LOWER(word), '%');判断是否命中 - 命中即设
SET NEW.flag_sensitive = 1;，并插入日志：INSERT INTO clean_log (post_id, matched_word, created_at) SELECT NEW.id, word, NOW() FROM sensitive_words WHERE LOWER(NEW.content) LIKE CONCAT('%', LOWER(word), '%'); - 应用层读到
flag_sensitive = 1后，再决定走人工审核、前端遮蔽或异步脱敏流程 - 如必须返回脱敏文本，由应用层或存储过程调用带缓存的 Trie/AC 自动机实现，而非触发器
触发器不是文本处理器——它最该做的，是快速打一个“这里可能有问题”的戳，而不是试图把文字修好。越想在触发器里一步到位，越容易在锁表、NULL 值、版本兼容性上翻车。
