MarkLogic 中 post-commit 触发器在单次文档更新后被触发两次，通常源于未显式禁用递归（recursive: false），导致触发器自身修改文档时再次激活同一触发器，形成隐式自触发循环。
marklogic 中 post-commit 触发器在单次文档更新后被触发两次，通常源于未显式禁用递归（`recursive: false`），导致触发器自身修改文档时再次激活同一触发器，形成隐式自触发循环。
在你的数据处理流水线中，第 6 步的 validateData.sjs 触发器监听 processed 集合上的 modify 事件，并在验证后通过 xdmp.documentInsert() 将文档重写至 export-ready 或 needs-review 集合——关键在于：该插入操作会同时修改文档元数据（如最后修改时间、集合列表）并触发一次新的“modify”事件，而默认情况下 MarkLogic 触发器的 recursive 参数为 true，即允许自身变更引发新一轮触发。
这意味着：
- 第一次触发：由步骤 5 的 xdmp.documentInsert(..., 'processed') 引起（原始 modify）；
- 第二次触发：由步骤 7 的 xdmp.documentInsert(..., 'export-ready') 或 ... 'needs-review' 引起——尽管集合已变更，但只要文档 URI 相同、且触发器作用于 collection-scope: "processed" + update-kind: "modify"，MarkLogic 仍会将该重写视为对原 processed 集合内文档的一次“修改”（因为集合变更属于文档元数据更新的一部分），从而再次命中同一触发器。
✅ 正确解法：显式设置 recursive: false
创建触发器时必须明确禁用递归，确保触发器逻辑产生的文档变更不会反向触发自身：
// 创建 validateData 触发器时，务必指定 recursive: false
trgr.createTrigger(
'validate-data-trigger',
'validateData.sjs',
trgr.triggerEvent(
trgr.collectionScope('processed'),
trgr.documentContent('modify')
),
trgr.triggerExecution('post-commit'),
// ? 关键：阻止自触发
{ 'recursive': false }
);
⚠️ 注意事项：
- recursive: false 仅阻止同一触发器实例的嵌套调用，不影响其他触发器（如 export-ready 集合上的新触发器）正常工作；
- 不要依赖“跳过日志”或“条件过滤 URI”来规避——这属于临时补丁，无法根除语义级触发风暴；
- 所有 post-commit 触发器均运行在独立事务中，因此 xdmp.documentInsert() 在其中的执行必然生成新事务，这是设计使然，而非 bug；
- 若需在验证后主动触发下游流程（如投递至消息队列），应改用 xdmp.invoke() 或 xdmp.spawn() 显式调用，而非依赖集合变更间接触发。
? 验证是否已修复：
在 validateData.sjs 开头添加唯一性日志标识（如 fn.currentDateTime() + fn.randomNumber()），并检查 QConsole 日志中是否仅出现一条匹配记录；若仍有两条，则需确认：
- 触发器是否被重复注册（可通过 trgr.listTriggers() 检查）；
- 是否存在其他监听 processed 集合的 trigger（例如误配的 create 触发器捕获了重写行为）；
- xdmp.documentInsert() 调用是否意外传入了 collections: ['processed']（即使目标是其他集合，残留 collection 值也可能干扰判断）。
遵循 recursive: false 原则，不仅能解决当前双触发问题，更是构建可预测、可维护的 MarkLogic 触发器链的基石。
