instead of触发器不拦截修改原操作，而是完全替代：写什么就执行什么，不写则原操作不发生；insert需显式写回基表，update须精准where关联inserted，delete为空则数据保留。
INSTEAD OF触发器不会“拦截并修改”原操作，它直接跳过原始INSERT/UPDATE/DELETE，只执行你写的代码——写什么就做什么，不写就不做，也不报错。
INSTEAD OF INSERT必须显式写回基表，否则数据根本不会入库
触发器激活后，inserted表里有数据，但基表一行都不会变，除非你主动用INSERT INTO ... SELECT FROM inserted写回去。常见错误是只校验、不插入，结果客户端以为成功，实际数据丢失。
- 多行插入时不能用
SELECT TOP 1取值——inserted是结果集，不是单行变量 - 字段映射必须严格匹配：视图含
full_name AS first_name + last_name，inserted.full_name就不能直接插进first_name和last_name字段 - 想返回自增ID？得用
OUTPUT INSERTED.id，SCOPE_IDENTITY()在触发器里无效 - 没加
SET NOCOUNT ON会导致ORM误判影响行数（比如认为插入0行=失败）
INSTEAD OF UPDATE要精准WHERE匹配，否则可能全表更新
SQL Server不帮你自动定位行，你必须自己用FROM inserted i WHERE t.id = i.id关联。漏掉FROM inserted或WHERE条件，UPDATE会作用到整张基表。
- 视图若含JOIN，必须暴露基表主键（如
t_Item.fitemid），否则无法精准定位 - 不能更新
IDENTITY列或计算列，但inserted里可以有占位值，触发器中跳过这些字段即可 - 需手动处理并发：比如用
IF NOT EXISTS (SELECT 1 FROM base_table WHERE id = (SELECT id FROM inserted))防重复插入 - 触发器内不能调用
UPDATE same_table，否则递归触发自身（TRIGGER_NESTLEVEL() > 1时应RETURN）
INSTEAD OF DELETE本质是“空操作”，拦不住TRUNCATE TABLE
INSTEAD OF DELETE能拦截DELETE FROM table，但对TRUNCATE TABLE完全无效——后者是DDL操作，不走DML流程，也不生成DELETED表。
- 最简防护写法是空
BEGIN END块，或加RAISERROR('禁止删除', 16, 1); ROLLBACK;（注意必须显式ROLLBACK） - 如果表有
ON DELETE CASCADE外键，SQL Server直接禁止创建该触发器，报错Msg 3724 - 别在触发器里写
DELETE FROM same_table，会递归触发，很快达到嵌套层级上限32 -
DELETED表结构按视图定义，不是基表结构；字符串比较建议加COLLATE DATABASE_DEFAULT防排序规则不一致
真正难的不是语法，是把业务逻辑完整搬到触发器里：外键顺序、空值默认、约束校验、日志记录、并发控制——每一步都得自己写，少一个环节就可能静默出错。
