WordPress 实时协作功能遇阻：7.0 版本发布推迟背后
背景：Phase 3 为何延期
Gutenberg 项目采用四阶段开发路线图：区块编辑器（Phase 1）、全站编辑（Phase 2）、实时协作（Phase 3）以及多语言能力集成（Phase 4）。
原定于 4 月 9 日发布的 WordPress 7.0，被寄予承担 Phase 3 上线的厚望，同时还要带来更多便于在 WordPress 中使用 AI 的功能。然而正式版并未如期到来——原因正是实时协作（Real-Time Collaboration，RTC）尚未达到稳定状态。
实时协作功能是什么
RTC 允许多个用户同时在区块编辑器中编辑内容和区块设计，对于出版商和代理商而言，这是一项实用的协作能力。WordPress.com 自 2025 年 10 月起已面向企业级 Beta 测试用户（WordPress VIP 客户）开放了该功能。
官方文档指出，RTC 与原生 WordPress 区块配合最佳；若第三方区块未严格遵循开发规范，则可能出现兼容性问题。
Beta 测试反馈如何
WordPress.org 官方发布的信息显示，RTC 在特定条件下的表现获得正面评价：
- 使用原生 WordPress 区块和遵循最佳实践的自定义区块构建的网站，协作体验流畅，问题极少
- 某大型研究机构的技术负责人表示，团队投入深入学习 Gutenberg 后，"从未遇到任何问题"
- 压力测试中，团队同时添加数十个区块、并行复制大量内容、多人协同编辑同一篇文章，RTC 均表现稳健
然而，上述测试使用的是复用现有数据表存储协作事件的旧版本。该方案导致多个 bug，最终团队决定新建专用数据表来提升稳定性，由此引发了版本延期。此外，旧版本默认限制了同时编辑的用户数量。
GitHub 问题单记录了旧方案的性能瓶颈：协作提供方被限制在较少的默认用户数内，以降低过载风险。引入专用数据表后，RTC 需要重新全面测试，而这正是各大主机商最担忧的环节。
是核心问题的症状，还是独立难题？
Yoast SEO 创始人 Joost de Valk 近期在一篇博客文章中，将 RTC 的困境视为 WordPress 本身深层问题的外显。他直言 WordPress 需要重写大量现有代码，使其更安全、更现代、更高效：
“WordPress 7.0 的推迟恰恰实时展示了这个问题。团队需要重新审视实时协作数据的存储方式——最初塞进 postmeta 的方案根本无法支撑。他们现在考虑使用自定义数据表。这正是典型模式：新功能撞上现有数据模型的极限，要么打补丁，要么暂停重新思考。”
但这一观点并非社区共识。Post Status Slack 频道上引发了激烈讨论，部分社区成员强烈反对"WordPress 需要大规模重构"的说法。
实时协作功能的市场需求
虽然核心开发者 Cromwell 认为实时协作功能的使用者有限，但从市场数据来看，这个判断可能过于保守。Atarim 协作插件的免费版本已安装在超过 1,000 个网站，而代理商和自由职业者使用过的网站数量更是突破了 120,000 家。这说明设计师、代理商和编辑团队对多人协作编辑的需求确实存在，并非小众场景。
AI 或成 WordPress 7.0 最大亮点
WordPress 四阶段路线图于 2018 年制定，当时无法预判 AI 今日的重要程度。但可以说，AI 集成才是 WordPress 7.0 最受期待的功能，而非协作本身。
不过，实时协作功能很可能会在 WordPress 7.0 中落地。作为核心功能而非插件发行，这个决策有其合理性：它能让自由职业者和代理商与客户、以及分布在不同国家的内部团队高效协作。
