INSTEAD OF INSERT 触发器彻底替换原插入操作，不自动校验或修改数据，需显式处理inserted表、集合逻辑、外键顺序、递归触发等；在视图上使用价值最大，表上使用易增一致性风险。
INSTEAD OF INSERT 触发器不会自动“拦截并修改”插入逻辑，它直接跳过原 INSERT，只执行你写的代码——写什么就做什么，不写就不做，也不报错。
为什么 INSTEAD OF INSERT 不等于“增强版 BEFORE INSERT”
它不是在原操作前加校验或改值，而是彻底替换整条 INSERT 语句。SQL Server 解析到 INSERT INTO view_or_table 后，如果目标上有 INSTEAD OF INSERT 触发器，就完全忽略原始语义，只进触发器体，inserted 表里有数据，但基表一行都不会变——除非你主动用 INSERT INTO ... SELECT FROM inserted 写回去。
- 不能依赖约束自动生效：比如主键冲突、NOT NULL 违反，这些在触发器外就被拦住了，根本进不到触发器里
- 字段映射必须显式：视图含计算列或别名时，
inserted表结构按视图定义，不是基表结构；inserted.full_name无法直接插进first_name + last_name的基表字段 - 没写
SET NOCOUNT ON容易让客户端误判影响行数（比如 ORM 认为插入失败）
多行插入时最容易漏掉的集合处理
inserted 表永远是结果集，不是单行变量。用 SELECT TOP 1 id FROM inserted 只能取第一行，批量插入会丢数据。
- 必须用集合操作：例如
INSERT INTO Orders SELECT order_id, customer_id FROM inserted - 需要逐行校验？改用
MERGE或在触发器内联LEFT JOIN查重，避免游标或循环 - 插入后要返回自增 ID？得用
OUTPUT INSERTED.id，不能靠SCOPE_IDENTITY()—— 那个只对直插有效
递归触发和跨对象写入的静默陷阱
在触发器里写 INSERT INTO same_table，哪怕加了条件，也会触发自身（如果数据库级 recursive_triggers 开启），报错 Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)。
- 视图上建
INSTEAD OF INSERT→ 插入基表 → 基表若有AFTER INSERT触发器 → 里面又更新同一基表 → 就可能二次激活自身 - 防御方法：开头加
IF TRIGGER_NESTLEVEL() > 1 RETURN，或用上下文标记（如SESSION_CONTEXT(N'trigger_skip')） - 外键顺序错位：比如先插子表订单项，再插父表订单，必然报
FOREIGN KEY constraint failed
真正想“拦截并修改”，得自己重写整个流程
比如想实现“存在则更新，不存在则插入”，不能指望触发器自动判断——你得手动查 EXISTS(SELECT 1 FROM base_table WHERE id IN (SELECT id FROM inserted))，再分两路走 UPDATE 和 INSERT。
- 别在触发器里调
NEWID()或GETDATE()做默认值：旧版本 SQL Server 对部分函数有上下文限制 - NULL 值透传要小心：视图字段允许 NULL，但基表字段是
NOT NULL，触发器里得补ISNULL(inserted.col, 'default')或显式RAISERROR - 日志记录要快：往日志表写
INSERT INTO log SELECT *, SUSER_SNAME(), GETDATE() FROM inserted是安全的，但别 JOIN 大表查用户详情
最常被忽略的一点：INSTEAD OF INSERT 在视图上才能发挥最大价值，在普通表上用它，往往意味着你在绕开约束体系、手动接管数据流——这本身就会放大一致性风险，尤其当多个应用路径共用同一张表时。
