本文约 4,712 字，预计阅读 12 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：上线三个月后才发现，内容和工具绑死了
选择构建器型产品的那一刻，你通常只考虑了“好不好用”。但真正决定长期成本的，是另外三个问题：我的页面数据存在哪里？如果停用它会变成什么？迁移到别家需要重做多少内容？
这三家的答案差异巨大。Elementor 把布局存在 post meta 的 JSON 里，正文可读性尚存；Divi 主要把结构写进 post_content 的短代码；Bricks 则以结构化的 post meta + 局部 Gutenberg 兼容的方式存储。不同的存储方式，直接决定了三年后的迁移难度。
如果你已经身处其中，本文提供的方法可以直接用；如果你正在选型，请把“退出成本”作为第一决策依据——这也是Hello Elementor 与容器类主题的取舍里强调的同一个原则。
原理分析：三种存储结构决定了三种命运
| 构建器 | 数据存放位置 | 正文特征 | 停用后的表现 | 迁移难度 |
|---|---|---|---|---|
| Elementor | _elementor_data (post meta) + _elementor_edit_mode |
post_content 里以 Gutenberg 区块形式存一份（通常是 <!-- wp:html --> 包装） |
裸 HTML 仍可读，样式大部分丢失 | 中 |
| Divi | post_content 内的 [et_pb_*] 短代码 + _et_pb_use_builder meta |
正文被短代码完全占据 | 页面上全是裸露的短代码文本 | 高 |
| Bricks | _bricks_page_content_2 (post meta) |
post_content 保留较强的可读 HTML | 输出相对干净，样式丢失 | 中低 |
核心结论是：内容离原生 Gutenberg 结构越近，迁移越容易。Divi 的短代码方式意味着 post_content 里全是 [et_pb_section ...] 这样的私有语法，一旦主题停用就是满屏乱码文本；而 Elementor 和 Bricks 在 post_content 里保留了更接近 HTML 的痕迹，至少能被搜索引擎和迁移工具识别。
另一个维度是 耦合面：Divi 既是主题又是构建器（强耦合），Elementor 是插件（可搭配任意主题），Bricks 是主题自带构建器（中耦合）。耦合越紧，卸载时需要处理的周边（主题自身的选项数据、配套插件、License）越多。
保姆级实操
第一步：先量化你被绑定了多少。
-- 统计有多少页面用了各家的构建器
SELECT 'Elementor' AS builder, COUNT(*) AS pages
FROM wp_posts p JOIN wp_postmeta m ON p.ID = m.post_id
WHERE m.meta_key = '_elementor_edit_mode'
UNION ALL
SELECT 'Divi', COUNT(*)
FROM wp_posts
WHERE post_content LIKE '%[et_pb_section%'
UNION ALL
SELECT 'Bricks', COUNT(*)
FROM wp_postmeta
WHERE meta_key LIKE '%_bricks_page_content%';
# 用 WP-CLI 快速跑上面的统计
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%[et_pb_section%';"
第二步：检查有多少内容是「纯构建器」而无法被原生编辑。
Elementor 用户常以为自己在用区块编辑器，其实正文可能是被 <!-- wp:html --> 包裹的一大坨 HTML。
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '<!-- wp:html -->%' AND post_type='page' LIMIT 20;"
命中数量越多，说明越多内容无法在未来享受区块编辑器的红利。
第三步：导出前先看结构化程度是否合理。
# 导出包含构建器元数据的完整 XML（注意：默认导出不含 meta，需要工具支持）
wp plugin install wordpress-importer --activate
wp export --dir=./wp-content/uploads/exports --start_date=1970-01-01 --post_type=page
标准 WordPress 导出（wxr）默认不包含 post meta，所以构建器的数据并不会随之导出。迁移必须依赖各家自己的 Import/Export 工具，这一点很多人忽略了。
第四步：做迁移前先把「锚主任医师」格式清洗出来。
Divi 用户迁移的第一步通常是用 wp search-replace 把短代码替换成原生区块，但这必须分步验证：
# 先在克隆环境试运行（--dry-run 只报告不写入）
wp search-replace '[et_pb_section' '' --include-columns=post_content --dry-run --network=0
# 确认影响行数与抽样内容后，再执行真实替换（务必先备份）
wp db export pre-divi-clean.sql
第五步：Elementor → 原生区块的渐进替换。
Elementor 用户可以按页面逐个「Convert to Blocks」，但付费部件不支持。更可控的做法是：
<?php
// mu-plugins/migration-helper.php —— 找出仅包含 HTML 区块的页面，优先处理它们
add_action( 'admin_menu', function () {
add_submenu_page(
'tools.php',
'迁移候选页',
'迁移候选页',
'manage_options',
'migration-candidates',
function () {
global $wpdb;
$rows = $wpdb->get_results(
"SELECT ID, post_title FROM {$wpdb->posts}
WHERE post_type='page' AND post_status='publish'
AND post_content REGEXP '<!-- wp:html -->'
LIMIT 100"
);
echo '<div class="wrap"><h1>可优先迁移的页面</h1><ol>';
foreach ( $rows as $r ) {
printf(
'<li><a href="%s">%s</a></li>',
esc_url( get_edit_post_link( $r->ID ) ),
esc_html( $r->post_title )
);
}
echo '</ol></div>';
}
);
} );
第六步：核对移除后的残留。
# 停用构建器后检查前台是否还有裸露短代码
curl -s https://example.com/sample-page/ | grep -o '\[et_pb_[a-z]*' | sort | uniq -c | head
# 期望输出为空
常见踩坑
- 以为
wp export能带走构建器布局。标准导出不带 post meta，布局必须靠各家导出器。 - 直接在生产环境跑
wp search-replace短代码替换。一旦替换后样式全丢且无法回退，务必先在克隆环境试运行并导出 SQL 备份。 - 忘了处理 Global widgets / Theme Builder 模板。它们在
wp_posts里是独立的 post type（elementor_library、et_pb_layout、bricks_template），主内容线索迁走了，引用它们的模板却没有跟上，页面上就会出现大片空白。 - 忽视 license 到期后的更新断供。Bricks 与 Elementor 的 License 到期只是不能更新，一般不影响既有站点运行；但 Divi 与 Élémentor Cloud 这类打包方案在计费结束后的策略需要看官方条款。
- 认为 Bricks 因为是主题所以“没有插件依赖”。实际上 Bricks 仍然引入自身的 class 与 API，只是耦合面比 Divi 少。
- 没有统计多语言站点的影响。WPML/Polylang 下同一页面每种语言都要重建模板，迁移量 × N。
- 案例：某客户从 Divi 迁到 Astra + Spectra，直接在新站导入旧站的 WXR 导出。前台出现大量
[et_pb_row]文本，且部分页面因为短代码未闭合导致 HTML 结构错乱、页脚被挤到正文中间。最终处理方式是：回退数据库 → 用wp post delete $(wp post list --post_type=page --format=ids) --force清空 → 重新编写核心页面。教训：跨建构器迁移本质上是一次重做，不是一次导入；把它当成内容重建项目来排期，而不是当成一次搬迁。
总结
选型判断标准：优先选把内容存在原生结构附近的工具。具体到三家：Elementor 生态最大但付费部件依赖强、迁移成本中；Bricks 性能好、数据结构相对干净，但社区规模较小、找人维护难；Divi 全家桶耦合最深，短代码方式让迁移代价最高。
行动清单无论选哪家都要做（停用构建器后还要按插件停用卸载后的残留数据清理处理它的 post meta 与定时任务）：每季度导出一次构建器自有的完整包 + 一份数据库备份；把高频模块做成可复用的全局部件而非逐页堆砌；关键落地页保留一份“纯 HTML”版本（哪怕是一个 <!-- wp:html --> 区块下的干净 HTML），日后工具不可用时不至于全站崩塌。
