结论先行：WordPress 核心团队明确表态，未来的多人实时协作（RTC）不再沿用「只在浏览器里合并编辑」的思路，改为 服务端感知（server-aware）、由 WordPress Core 掌控 的方案。触发这次转向的是两个无法在客户端修补的死结——服务器无法确认「谁写了什么」，以及服务器自己无法参与协作会话。对普通站长的直接影响是：短期内不会等到「像 Google Docs 那样多人同时改一篇文章」的原生功能，但也不会因此拿到一个存在权限绕过风险的半成品。
7.0 为什么把实时协作撤了下来
今年早些时候，WordPress 7.0 在临近发布时移除了已经开发多时的实时协作功能。背后的原因不是人手不够，而是社区提出的安全问题足够硬：当所有合并逻辑都发生在浏览器里时，WordPress 的服务端其实对会话中发生了什么一无所知。
现在的实验实现思路是这样的：每个打开文章的浏览器各自持有一份基于 CRDT 的文档副本，浏览器之间互相交换更新，直到所有副本内容一致。改动在被保存之前，只存在于浏览器内存中。
这个设计有个合理的出发点——它和区块编辑器本身的工作方式一致：编辑器在浏览器里干活，写完了把成品交给 WordPress 。客户端方案对核心代码改动小、响应也更跟手。但它把两件事留在了原地没解决。
死结一：服务器不知道「谁写了什么」
服务端在协作会话期间没有任何能力去归因单条编辑。即使客户端老老实实提供了「这段是谁改的」元数据，服务端也只有两个选择：无条件相信它，或者干脆认定整篇内容都归那个人所有。
两种选择都会绕过权限检查。核心团队给了一个很具体的例子：
- 一个没有发布原始 HTML 权限的作者，和一个管理员，正在同一篇文章上协作。
- 作者插入了一个包含
<script>标签的区块，这个改动被同步到了管理员的编辑器里。 - 管理员在文章的另一处改了个错别字，点了保存。
- 整篇文章最终以管理员的权限写入数据库，包括那段管理员从来没看过的脚本。
这就是所谓的「内容洗白」：低权限用户把自己的内容搭在别人的提交上，借高权限账号的壳落地。放在多人协作的编辑部、外包写手的站点、或者开放投稿的内容站上，这是实打实的风险。
死结二：服务器插不上话
第二个问题更根本。当前的协作只对浏览器客户端开放。任何经由服务器流动的更新——通过 REST API 写回的、通过 WP-CLI 跑的脚本——都没法同步给正在编辑的其他人，只能整篇覆盖。
核心团队举的场景是自动化脚本写回：一个脚本在 09:00 抓取了一篇文章，09:03 把改好的版本写回。它并不知道 09:01 已经有两位编辑打开了这篇文章开始修改。脚本执行完，他们的工作就没了。
麻烦的地方在于补救方式：浏览器确实能收到「有变更」的通知，但服务器没法告诉它们变的是哪一段，只能告诉它们「变了」。编辑器于是只剩两个选项——整体接受服务器上的新版本，或者整体丢弃。无论选哪个，双方必有一方的工作白做。
一旦把 WordPress 用成内容中台，这个坑会非常显眼：定时同步脚本、 AI 自动补全摘要、批量改分类法、导入外部数据——这些都属于「服务器侧写入」，全都会和人工编辑打架。
「服务端感知」到底指什么
转向的含义是：协作状态不再只活在浏览器内存里，而是由核心掌握并能被服务器理解。这样才有条件做到三件当前做不到的事——服务器能校验权限、能归因到人、也能把服务器侧的变更以「可合并」而非「全量覆盖」的形式发出去。
| 维度 | 当前实验（纯浏览器 / CRDT） | 新方向（服务端感知） |
|---|---|---|
| 合并发生的位置 | 浏览器之间互相同步 | 状态由核心掌握，服务端可参与 |
| 保存前的数据 | 只存在浏览器内存 | 服务器可见，可校验 |
| 权限校验 | 只能信客户端，或整篇归最后保存者 | 可对单条编辑归因，按编辑者权限判定 |
| REST API / WP-CLI 写入 | 整篇覆盖，可能冲掉他人工作 | 可被感知、可被合并，不必二选一 |
| 核心改动量 | 较小 | 明显更大 |
| 当前状态 | 7.0 已移除 | 重定方向，尚未成型 |
对站长和开发者的现实影响
- 短期内没有原生的「多人同时在线改一稿」。想同步协作，仍然只能靠第三方插件或外部工具。挑选这类插件时，把「谁有权改什么」这条问清楚，比看演示效果重要得多。
- 服务器侧写入的冲突是真实存在的，而且不限于协作场景。哪怕只有一个编辑在改稿，自动化脚本整篇覆盖也可能干掉他的改动。凡是「读取—修改—写回」的脚本，都应该改成只改目标字段、并在写回前带上版本校验。
- 修订版本和备份的价值被放大了。服务器侧覆盖不会留下「合并失败」的痕迹，只能靠修订历史和备份回溯。
- 主题与插件开发者可以提前对齐数据结构。新方案要求编辑能按人归因，意味着区块/文章元数据层面需要更清晰的边界。现在就把自定义字段设计成「可独立寻址的小块」，将来适配成本更低。
顺带说一句，WordPress 近一年的方向信息密度很高。如果你还在消化别的变化，可以对照着看：WordPress 7.2 路线图 里提到的 sudo 模式与 Secrets API，本质上都在把「谁在做什么、用什么凭证」这件事往核心层收；这和 RTC 转向服务端的思路是一致的。
现在就该做的 5 件事
- 协作流程上明确一个最终保存者，其他人只提交片段而不是整篇覆盖。这是零成本、立刻生效的做法。
- 不要整篇 PUT 回去。只更新需要动的字段，并在请求里带上写入前的修订校验，发现版本已变就停止并告警。
- 给自动化脚本单独建应用密码和专用账号，按最小权限授角色。这样即使脚本写回被滥用，也不会以管理员身份落地内容。
- 检查自定义字段、短代码、以及任何会原样输出用户输入的区块。文章里那个 script 标签的例子，落在你自己的站点上就是 XSS 。先梳理 WordPress 钩子（Hooks）的过滤器，看有没有该过滤而没过滤的输出点。
- 每次脚本写回前先落一份修订或备份到独立存储。协作冲突没法自动合并时，至少能人工找回丢失的改动。
常见问题
WordPress 还会不会做多人实时协作？
会，而且方向已经明确：服务端感知、由核心掌控。变化的是实现路径，不是要不要做。核心团队已经承认当前客户端方案无法解决权限归因和服务器参与这两个问题，所以重定方向而不是在旧方案上打补丁。
这个改动和我用第三方协作插件有什么关系？
没有直接冲突，但选型标准应该一致。第三方插件同样要回答「谁有权改什么」——如果你的角色权限体系里作者不能发布原始 HTML，而协作插件允许他通过同步绕过去，那就是同一个漏洞换了个实现。
我想保住多人编辑时的工作成果，眼下最有效的一步是什么？
先把服务器侧写入改成字段级更新 + 版本校验。绝大多数「我的改动莫名其妙消失了」都发生在自动化脚本整篇覆盖的场景，而不是真正的人类并发编辑。这一步不需要等官方新方案。
补充说明
关于短代码写法，本文用到的几个都是主题原生的：提示框写成 [jinyu_tip type=”info”]…[/jinyu_tip]，折叠区写成 [jinyu_collapse title=”标题”]…[/jinyu_collapse]，按钮写成 [jinyu_btn]；分步教程用 [jinyu_howto] 包住若干 [jinyu_step]，问答则用 [jinyu_faq] 包住 [jinyu_faq_item q=”问题”]。注意方括号在实际书写时要用实体编码显示，否则会被主题直接解析。
如果后续要做核心贡献或跟踪提案进度，可以配合官方此前上线的 Trac MCP 服务器，让 AI 先把相关工单和时间线筛一遍，再人工读细节，比在 Trac 里翻页快得多。想系统补一遍编辑器与站点编辑的基础，全站编辑（FSE）实战是更划算的起点。
评论 (0)