构建者完整性可在内容问题演变为实际问题之前，检测 WordPress 编辑器及页面构建器的相关问题。

它能检测的内容

当编辑器状态与存储内容不再一致时。

WordPress 内容可能会累积过时的编辑器信号、畸形的块结构、混合的构建器状态，或与当前渲染内容不符的元数据。构建者完整性会在决定是否需要修复之前，先对这些信号进行分离。

即使存储的编辑器状态已经不一致，WordPress 页面仍可能继续正常渲染。页面中可能出现 Gutenberg 块注释与构建器元数据并存的情况，旧的 Elementor 数据在内容变更后依然残留，或者畸形的块分隔符隐藏至下一次编辑才被发现。这些状况从前端难以诊断，因为可见输出可能仍显得正常。

构建者完整性直接检查存储内容和编辑器信号，区分明确的构建器证据与较弱的历史标记，然后对记录进行分类，而非简单地以某一元数据值来判定活跃的编辑器。这使得诊断结果在迁移、内容清理、翻译工作流等场景中更具参考价值。 REEID Translate, 主题更换或排查意外的编辑器行为时。

为何要检查编辑器完整性？

构建者完整性发挥作用的场景。

编辑器不一致往往只有在有人打开页面进行编辑、切换构建器、执行迁移、翻译内容或更新插件时才会显现。提前检测状态，可为您提供更清晰的起点。

对于 Gutenberg 内容，构建者完整性会检查块注释的结构，而不仅仅依赖于 WordPress 是否能够渲染该页面。它可以识别孤立的闭合标记、不匹配的分隔符、未闭合的块、无效的块属性 JSON，以及可能被误认为普通 HTML 的畸形 WordPress 块注释。

如需对存储的 Gutenberg 标记进行更深入的人工检查，请参阅 Gutenberg 块源编辑器。

对于 Elementor 和 SiteOrigin，插件会分别记录构建器特有的证据，与 Gutenberg 和经典内容的信号分开。这在记录曾被多个系统多次编辑，或在工作流程变更后仍有旧的构建器元数据残留时尤为有用。

目标是诊断，而非激进清理。混合或异常的状态并不会自动被视为需要重写的内容。不在狭窄修复规则范围内的记录仍将保留人工审核的机会，而非被自动更改。

0.1.0 版本支持

设计上较为保守。

首个版本侧重于检测与诊断，自动变异功能被刻意限制。Builder Integrity 不会尝试对 Gutenberg 进行大规模重构或迁移构建器。

• 基于 WordPress 管理后台的有限站点诊断
• 逐条记录的诊断
• WP-CLI 扫描
• Gutenberg 结构性故障检测
• Elementor 和 SiteOrigin 状态检测
• 经典/非区块内容检测
• 针对一个支持度较低的缺失 Gutenberg 区块，审核了修复方案并予以推进
• 在执行支持的修复前，已验证对应的 WordPress 修订版本
• 写入后进行验证，若失败则尝试回滚

Builder Integrity 不会将站点内容发送至外部服务，也不包含遥测功能。

首个版本不支持的功能

0.1.0 版本不会尝试对 Gutenberg 进行整体重构、自动转换构建器、批量重写内容或清理隐藏元数据。大多数检测到的不一致信息仍将作为诊断数据保留，除非插件能够制定出范围明确且确定性的修复方案。

当有支持的修复方案可用时，会将当前内容与经审核的预览进行比对，验证或创建相应的 WordPress 修订版本，写入变更，并再次扫描结果。若验证失败，Builder Integrity 将尝试从该修订版本恢复原始内容。

Builder Integrity 面向哪些用户？

Builder Integrity 专为需要在编辑、迁移或修复内容之前了解其实际存储方式的 WordPress 管理员、开发者、机构及站点维护者而设计。管理端诊断提供有限的站点扫描与单条记录检查，而 WP-CLI 则为技术审计及大型站点提供了相同的分类工作流程。