sql server 明确禁止在触发器内使用 output 子句，报错 msg 334，因执行时序冲突与状态不确定性；必须将 output 移至触发器外部，用 output into @table_variable 或 #temp 捕获数据，且接收表不能含触发器、fk 或 check 约束。
SQL Server 触发器里用 OUTPUT 直接报错 Msg 334
不能用。SQL Server 明确禁止在触发器内使用 OUTPUT 子句，无论目标是 INSERTED 还是 DELETED，只要语句出现在触发器体中，就会触发错误：Msg 334, Level 16: "The OUTPUT clause cannot be specified in a trigger."
这不是语法写错了，也不是权限问题，而是 SQL Server 强制的引擎级限制——它不让你在触发器上下文中启动任何带 OUTPUT 的 DML。
为什么触发器里 OUTPUT 被禁用？
根本原因是执行时序冲突和状态不确定性：
- 触发器（尤其是
AFTER类型）在 DML 主体执行后、事务提交前运行，此时数据可能被再次修改 -
OUTPUT设计为“立即返回变更瞬间的快照”，但触发器里的 DML 并非独立操作，它的INSERTED/DELETED伪表语义与外层 DML 混叠，SQL Server 无法保证返回值是触发器前还是触发器后的状态 - 允许触发器内用
OUTPUT会破坏事务原子性和执行计划可预测性，所以直接封禁
想在有触发器的表上做审计，怎么办？
绕过触发器限制的唯一可靠路径，是把 OUTPUT 移到触发器外部，用 OUTPUT INTO @table_variable 先捕获，再处理：
- 必须用
INTO，不能只写OUTPUT DELETED.*, INSERTED.*—— 后者会被触发器直接拦截 - 目标只能是表变量或本地临时表（如
#temp），不能是永久表（尤其不能是带触发器、FK 或 CHECK 约束的表） - 如果原表已有触发器，且你又需要记录操作人、时间等上下文，得提前声明变量（如
@operator、@op_time），并在OUTPUT列表里显式带上它们 - 别指望
OUTPUT INTO AuditLog一步到位：高并发下容易锁争用，也违反“审计表不应与业务表强耦合”的设计原则
替代方案对比：触发器 vs OUTPUT vs CDC
真要补审计逻辑，得看清约束边界：
- 已有触发器 → 只能改外层 DML +
OUTPUT INTO，不能动触发器本身加OUTPUT - 没触发器但需轻量审计 →
OUTPUT是首选，性能好、事务一致、无额外维护成本 - 要全量、长期、解耦的变更流 → 考虑
CDC（Change Data Capture），但它需要额外开启、占用msdb和tempdb，且不适用于 Azure SQL 托管实例 - 千万别在触发器里嵌套
INSERT ... OUTPUT去写日志表——这会触发Msg 334，而且极易引发死锁
最常被忽略的一点：即使你把 OUTPUT 写对了，只要目标表（比如审计表）自己定义了触发器，OUTPUT INTO 依然会失败。检查 sys.triggers，确保接收表干净。
