不能安全可靠地用SQL触发器自动过滤敏感词，应改用打标+阻断+日志记录，清洗逻辑必须移出数据库。
不能安全、可靠地用 SQL 触发器在数据入库时自动“过滤”敏感词。所谓“过滤”（即字符串替换）会破坏语义、漏判变体、触发 NULL 值、导致字段超长，甚至中断写入。真正可落地的做法是：**打标 + 阻断 + 日志记录**，清洗逻辑必须移出数据库。
BEFORE INSERT 里用 REPLACE() 批量替敏感词为什么崩
常见错误是循环调用 REPLACE(NEW.content, 'xxx', '***')，但实际执行时立刻暴露四类硬伤：
- 顺序依赖：词库含“小”和“小明”，先替“小”导致“小明”变“***明”，后替“小明”完全失效
- 大小写/全角/空格绕过：
REPLACE()默认严格匹配，'Sex'、'sex'、's e x'全部逃逸 - 字段截断风险：多次
REPLACE()拼接可能让TEXT字段超长，触发ERROR 1406 (22001): Data too long - 无匹配反馈：
REPLACE()对未命中词返回原串，无法知道是否真有敏感词，后续打标或日志全靠猜
SELECT INTO @var 在触发器里为什么危险
典型错误写法是 SELECT word INTO @sw FROM sensitive_words LIMIT 1;，隐患直接落地：
- 没
WHERE条件，只取任意一个词，根本遍历不了词库 -
@sw是用户变量，跨会话可能残留旧值；MySQL 8.0.23+ 中行为已不稳定 - 若
sensitive_words表为空，@sw变为NULL→REPLACE(NEW.content, NULL, '***')返回NULL→ 整个NEW.content变NULL - 没校验是否真命中，
NEW.flag_sensitive无法设准
真正该用触发器做的三件事：打标、阻断、记日志
触发器唯一稳妥的角色是“检查+标记+拦截”，不是“清洗+改写”。重点落在业务可控、逻辑可追溯：
- 用
SIGNAL SQLSTATE '45000'主动中断非法插入，例如检测到高危词：IF NEW.content REGEXP '(?i)\b(admin|root|drop)\b' THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '含系统级敏感词,拒绝写入'; END IF; - 加字段打标：
SET NEW.flag_sensitive = 1;，后续由应用层决定是否人工复核、异步脱敏或拒审 - 写日志表（非触发表）：
INSERT INTO clean_log (post_id, field, matched_word, created_at) VALUES (NEW.id, 'content', 'xxx', NOW()); - 所有匹配必须基于标准化输入：统一用
LOWER(NEW.content)+COLLATE utf8mb4_0900_as_cs校对规则，避免大小写漏判
如果业务强要求替换，必须绕开触发器
把敏感词处理逻辑移出数据库，这是多数生产系统的实际做法：
- 应用层用专用库（如 Python 的
ahocorasick、Java 的 DFA 实现）做多模匹配，支持前缀树、跳转表、大小写/全半角/空格归一化 - 替换结果带上下文留痕，例如
CONCAT('【已过滤】', SUBSTRING(NEW.content, 1, 50))，比“干净”更重要 - 避免对
TEXT字段全文正则扫描——触发器执行期间锁行，大文本 + 多词库 = 明显延迟，甚至阻塞写入
真正容易被忽略的点是：**触发器看不到原始 SQL 字符串，也收不到请求头、参数绑定信息，它只看到已解析、已权限校验、已类型转换后的 NEW 值**。这意味着任何依赖“输入原始形态”的判断（比如 URL 编码、注释绕过、大小写混用）在触发器里天然失效。
