不能直接用一对普通触发器实现安全可靠的双向镜像，否则会陷入无限递归或主键冲突；因表a触发器写入表b后，b的触发器又反向写回a，形成循环，sql server虽可用trigger_nestlevel()>1拦截，但跨链接服务器时该函数失效，仍需sync_flag等字段辅助过滤，且删除操作易致双删，强依赖时间戳和来源标记，生产环境应优先选用事务复制（@loopback_detection=true）或对等复制。
不能直接用一对普通触发器实现安全可靠的双向镜像，否则会陷入无限递归或主键冲突——这是最常被忽略的前提。
为什么 AFTER INSERT/UPDATE 触发器在双向场景下会死循环
当表 A 的触发器把变更写入表 B，而表 B 上也挂着同步回 A 的触发器时，B 的变更又会触发 A 的触发器，如此往复。SQL Server 默认不限制嵌套层级，TRIGGER_NESTLEVEL() 会一路涨到 32 然后报错 Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)。
- 必须在每个触发器开头加
IF TRIGGER_NESTLEVEL() > 1 RETURN拦截间接调用 - 但仅靠这个还不够：如果两个触发器同时生效，仍可能因执行顺序导致数据覆盖或丢失
- 链接服务器跨实例同步时，
TRIGGER_NESTLEVEL()在远端不生效，需额外靠业务标识字段（如sync_flag）过滤
如何用触发器做「伪双向」——实际是单向 + 补偿逻辑
真正的双向镜像应由 SQL Server 原生机制（如对等复制、事务复制 with @loopback_detection = TRUE）承担。若只能用触发器，推荐拆成两个独立单向通道，并人工规避冲突：
- 表 A → 表 B：在 A 上建
AFTER INSERT, UPDATE, DELETE触发器，同步时检查inserted和deleted，并设置目标表的last_sync_from = 'A' - 表 B → 表 A：在 B 上建同类型触发器，但同步前加条件
WHERE last_sync_from 'B'，避免自己改自己再推回去 - 两表必须有统一的时间戳字段（如
updated_at）和来源标记字段（如sync_source），否则无法判断谁该赢 - 删除操作尤其危险：A 删了一行，B 触发器还没来得及同步，此时 B 本地又被删一次，会导致 A 的触发器误判为“B 主动删”，从而在 A 上也删——结果双删
跨服务器同步时链接服务器引发的主键冲突
用 LinkServer.DB.dbo.B 写远程表时，如果远程 B 表上也有触发器且未设 @loopback_detection，它收到变更后仍会尝试回写源表，而远程服务器识别不到本地的 TRIGGER_NESTLEVEL()，极易触发 Violation of PRIMARY KEY constraint。
- 务必在远程目标表上禁用所有可能反向写回的触发器，或用
DISABLE TRIGGER ALL ON B - 链接服务器查询必须用四部分命名法：
ServerName.DatabaseName.SchemaName.TableName，缺一不可，否则可能连错库 - 远程插入失败时，整个事务回滚——这意味着源表变更也会撤销，业务上要接受这种强一致性约束
真正需要双向实时同步的生产环境，别硬扛触发器；优先评估 sp_addsubscription 配合 @loopback_detection = TRUE 的事务复制，或者 Azure SQL 托管实例的对等复制。触发器只适合单向、低频、非关键链路的轻量同步。
