不能。触发器在SQL解析完成、权限校验通过后才执行，仅处理已解析的NEW值，无法拦截改变语句结构的SQL注入；它不接收原始SQL字符串，既易误杀正常数据（如“O’Reilly”），又无法防御参数化绕过或拼接型注入，真正防护应靠应用层参数化查询与最小权限原则。
触发器能拦住 SQL 注入吗
不能。触发器在数据已进入 SQL 解析流程、语义合法且权限通过后才执行，它根本收不到原始 SQL 字符串，只看到最终要插入/更新的 NEW 值。所谓“用触发器过滤非法字符串”，本质是做应用层该干的事——而放在数据库层，既漏报又误杀，还掩盖真实风险。
为什么 BEFORE INSERT/UPDATE 触发器拦不住注入
常见误解是：在触发器里对 NEW.content 做正则替换或截断，就能“消毒”。但问题在于：
- SQL 注入成功的关键是**改变语句结构**（比如闭合引号、拼接
OR 1=1），不是内容里含敏感词；触发器看到的已是解析后的值，攻击早已完成 - 如果攻击者走的是参数化查询绕过（如
WHERE id = ?），压根不会进触发器逻辑；如果是拼接字符串进 DB，那问题出在应用没预处理，触发器只是事后擦屁股 - 对
NEW.title强制删掉所有单引号，会导致正常用户存 “O’Reilly” 变成 “OReilly”——这不是防护，是数据损坏
真正在意数据安全时该盯住哪几处
防护必须分层，每层各司其职：
- 应用层强制用
PreparedStatement（Java）、pg_query_params()（PHP/PgSQL）、sqlite3_bind_text()（C）等参数化接口，杜绝字符串拼接 - 数据库账号权限最小化：写入表的账号，不给
CREATE FUNCTION、EXECUTE或访问系统表的权限 - 如确需动态字段校验（比如评论含敏感词），应在应用层调用独立服务或规则引擎，而非塞进触发器——否则查词逻辑一升级就得改 DB 结构
- 日志里记录原始请求体（脱敏后）和绑定参数，而不是依赖触发器“发现异常”
万一非要用触发器做内容清洗，注意这三点
仅限遗留系统无法改应用代码的极端情况：
- 只对明确业务含义的字段操作，比如
NEW.phone去除非数字字符，别碰NEW.note这类自由文本 - 清洗逻辑必须幂等且可逆：用
REGEXP_REPLACE(NEW.body, '[^\w\s]', '', 'g')比REPLACE(NEW.body, '''', '')更可控，但依然不防注入 - 触发器里禁止调用外部函数（如
curl、system()），PostgreSQL 的plpythonu等非安全语言扩展会直接扩大攻击面
实际项目里，花半天调触发器正则，不如花二十分钟把三个 query("SELECT * FROM user WHERE name = '"+name+"'" 改成参数化。真正难的从来不是“怎么拦”，而是“怎么让所有人不再拼 SQL”。
