WordPress 7.0 将移除实时协作功能，暂缓上线但已敲定未来最优技术方案

原计划4月9日发布的WordPress 7.0，因需细致打磨实时协作功能而延期，至今已延期一个月。

今天终于连发两篇重磅公告，都是围绕「实时协作（RTC：Real-time collaboration）功能」做出关键决策：正式宣布该功能将从即将发布的 WordPress 7.0 中移除，但另一方面也同步公布了实时协作功能的性能测试完整结果，明确了未来迭代的最优技术方案，为该功能后续回归做好了铺垫。

实时协作功能暂别 WordPress 7.0

WordPress 正式宣布决定将实时协作（RTC）功能从 WordPress 7.0 版本中移除，这一决定并非否定该功能的价值，而是基于对版本稳定性的严谨考量，官方目前对实时协作功能的现有实现方案缺乏足够信心，认为其暂未达到并入 WordPress 核心的稳健标准。

官方明确列出了移除该功能的核心顾虑，主要集中在5个方面：

影响面过大（surface area），可能对核心系统产生不可控影响；
存在竞态条件（race conditions），易导致数据同步异常；
服务器负载控制不佳，可能影响站点运行效率；
内存效率有待优化，存在资源浪费风险；
模糊测试（fuzz testing）中持续发现漏洞，稳定性无法保障。

WordPress 官方表示，这是一个艰难但必要的决定，尤其是实时协作功能已投入大量研发精力，但为了向全球用户交付稳定、可靠的 WordPress 7.0 版本，暂时移除该功能是最优选择。

实时协作仍然是 WordPress 一项重要且令人兴奋的功能，依然是 WordPress 未来重点推进的重要功能，待 WordPress 7.0 版本的相关清理工作完成后，将公布更广泛的测试计划与持续迭代路线，全力推动该功能在未来版本中达到发布标准。

实时协作功能同步复盘和性能测试

在官宣移除功能的同时，WordPress 官方同步发布了实时协作性能测试结果，披露了此前针对该功能开展的多环境压力测试详情。这意味着，虽然实时协作暂不上线，但官方已完成技术方案的打磨，为后续迭代做好了充分准备。

1. 测试背景与范围

为找到实时协作功能的最优存储方案，官方此前发起了主机环境测试号召，在 4 月 29 日至 5 月 4 日期间，共收到来自8种主机环境的测试数据（覆盖共享主机、带 Redis 的共享主机、托管云主机、无对象缓存主机等）。

测试工具在持续30秒的轮询窗口内，记录了每次请求的 REST 分发时间与数据库查询次数，最终完成了对汇总后匿名数据的全面分析。

2. 四种候选存储方案对比

本次测试针对实时协作功能的4种候选存储方案，在压力环境下进行了全面对比，具体包括：

post-meta：作为 RC2 版本的基准方案，也是最初的实现方式；
custom-table：为实时协作数据单独创建专用数据表，实现数据隔离；
post-meta-transients：使用文章元数据存储核心数据，配合瞬时缓存实现客户端状态感知；
custom-table-with-transients：专用数据表，配合瞬时缓存实现客户端状态感知。

3. 测试核心结论

测试数据显示，custom-table-with-transients 方案表现最优，成为官方推荐的未来默认存储方案，具体优势如下：

性能领先：在7套完整测试环境中，有6套排名第一或并列第一，性能从未低于基准方案（post-meta）；平均比当前实现快约52%，远超纯 custom-table 方案（快约37%）。
适配性强：在无持久化对象缓存的主机上，与纯 custom-table 方案差距仅为0.05–0.17毫秒，基本持平；在有持久化对象缓存的环境中，可将每次请求的数据库查询次数降至1次，优势显著。
降级平稳：在本次覆盖的全档次主机环境中，均能保持稳定表现，不会出现极端异常。

与之形成对比的是，post-meta-transients 方案被明确不推荐，甚至不适合作为降级方案。该方案在无持久化缓存时，延迟几乎翻倍；在某台无缓存共享主机上，还出现极端异常代码路径，导致调度延迟超过超过26毫秒，远差于其他所有方案。

此外，测试还发现两个关键信号：一是有持久化对象缓存时，两种基于瞬时缓存的策略（post-meta-transients 和 custom-table-with-transients）均能将数据库查询次数降至1次；二是无论是否开启缓存，custom-table 数据表结构相比post-meta 方案，查询数量几乎减半。