INSTEAD OF触发器只能基于inserted/deleted或NEW/OLD伪表中的数据快照进行条件判断，无法获取原始SQL、客户端IP、应用名等上下文，故不能识别SQL注入或替代权限校验；适用于字段级业务规则拦截（如禁删admin用户），但对TRUNCATE、DROP等DDL操作无效，需用DDL触发器单独处理。
不能直接拦截“非法请求”，只能拦截特定 DML 语句并做条件判断——INSTEAD OF 触发器不看 SQL 文本，只处理已解析的行集。
INSTEAD OF触发器能拿到什么数据？
它只接收 inserted 或 deleted 这类伪表（SQL Server）或 NEW/OLD 记录（PostgreSQL），里面是语句执行后“本该插入/删除”的数据快照。原始 SQL 字符串、客户端 IP、应用名、调用堆栈等一概不可见。
- 无法识别
' OR 1=1 --这类注入痕迹——语句早已被解析成合法执行计划 - 不能靠
APP_NAME()或HOST_NAME()做安全判断：连接池常用固定账号，字段值恒定且易伪造 -
USER_NAME()返回的是会话登录用户，不是发起请求的应用身份，权限校验应前置到应用层或登录触发器
哪些场景下可以“拦截并记录”？
适用于你明确定义了“非法”的业务规则，且该规则能基于伪表中的字段值判断，比如禁止删除 admin 用户、插入超限金额、更新已归档订单等。
- 必须用
deleted表判断 DELETE 是否违规，而不是查基表——否则可能死锁 - 日志写入要轻量：只存
ERROR_NUMBER()、ERROR_MESSAGE()、操作类型、时间、触发器名，避免查视图或调外部存储过程 - SQL Server 中建议在
TRY...CATCH块里捕获逻辑错误（如除零、转换失败），但注意RAISERROR后必须RETURN，否则后续语句仍会执行
为什么 TRUNCATE 和 DROP 不会被拦住？
TRUNCATE TABLE 是 DDL 操作，不走 DML 触发器链；DROP TABLE 更是对象定义变更，必须用数据库级 DDL 触发器单独监听 DROP_TABLE 事件。
-
INSTEAD OF DELETE对TRUNCATE完全无效——它甚至不生成deleted表 - 想防误删整表，得另建
CREATE TRIGGER tr_deny_drop ON DATABASE FOR DROP_TABLE - DDL 触发器不能跨库，也不能用
ROLLBACK阻止系统级操作（如ALTER DATABASE），需用EVENTDATA()提取上下文再决定是否RAISERROR
真正难防的从来不是某条 DELETE，而是权限模型松散 + 缺少操作审计 + 误用高权限账号连库。触发器只是最后一道窄缝，别把它当防火墙用。
