WordPress 7.1 特性与升级指南：新特性、兼容性风险与安全测试流程

WordPress 7.1 是 2026 年第二个大版本，定于 8 月 19 日发布。它在 7.0 的基础上加入了原生响应式样式、重构后的客户端图片处理、更强的 Notes 协作、两个新区块。整体思路是把已有系统打磨得更顺手，而不是重铺地基——所以对绝大多数站点来说，7.1 的升级风险比 7.0 更低。

核心要点

• 发布日期：WordPress 7.1 计划于 2026 年 8 月 19 日发布，官方仍标注为"暂定"，如果最后一刻出问题可能推迟。
• 经典区块保留：如果你一直用老的、更简单的编辑器写文章，什么都不会变。原本计划把经典区块从插入器里藏起来的提案，已在 2026 年 7 月 7 日被撤回。
• 响应式设计控件更容易用：现在可以直接调整站点在手机和平板上的样式，以及按钮在鼠标悬停时的反应，全程不用写代码。
• 图片上传更快：WordPress 7.1 的客户端图片处理会在访客浏览器里完成图片预处理，服务器压力更小。
• 几个呼声高的功能没赶上：实时协作编辑、底层 React 19 升级、以及两个小功能都被推迟到后续版本。
• 大多数站点升级无需担心：真正的风险只集中在自定义功能和一些老插件上，本文会讲清楚怎么排查。

什么时候发布？现在能升级了吗？

WordPress 7.1 定于 2026 年 8 月 19 日发布，正好是 WordCamp US（WordPress 一年一度的大型年会）在美国凤凰城闭幕的那一天。目前处于最后的测试阶段——Release Candidate（候选发布），从 8 月 5 日开始。到这个阶段功能已经冻结，发布日之前不会再有新东西加进来。

日期在官方路线图上仍然标着"暂定"。WordPress 之前也推迟过大版本——7.0 就从原定的 4 月往后挪过。所以按 8 月 19 日安排计划可以，但不要把产品上线或者客户交付卡在这个日期上。

要不要一发布就升级？线上站不要。任何 WordPress 大版本升级的安全做法都一样：先做一份站点副本，在副本上升级，确认所有功能正常，再动真站。这份副本叫 staging（预发布环境），后面会讲怎么做。升级前先做一次完整备份，出问题时能回滚。对简单站点来说这只是 5 分钟的检查；对插件多或者设计定制过的站点，这就是"平静升级"和"手忙脚乱"的分水岭。

如果你的站点托管在 SiteGround，WordPress 大版本会在发布 24 小时后自动安装，并且升级前会先自动做一次完整备份。要改延迟时间、进一步推迟、或者跳过某个版本，去 Site Tools → WordPress → Autoupdate 里设置。

小技巧：不用等 staging 搭好，现在就可以先检查一遍插件。WordPress 官方插件目录里每个插件页面都有一行"Tested up to"，写着开发者测试过的最新 WordPress 版本。打开你最重要几个插件的页面看一眼——超过一年没更新，或者只标注兼容到 7.0 的插件，就是升级后出问题的头号嫌疑人。你也可以直接让 SiteGround 的 WordPress AI Agent 帮你列出当前启用的插件，并检查它们对 7.1 的兼容性和更新状态。

WordPress 7.1 到底新增了什么？

7.1 是打磨型版本，不是重构型。两个最大的项目——响应式样式和客户端图片处理——都不是全新的：7.0 已经引入，7.1 是在此基础上扩展。真正全新的东西是：交互式样式控件、两个新区块、图标集添加方式、以及编辑器加载方式的底层改动。下面逐个讲。

响应式样式：不用写 CSS

CSS 是控制网站外观的代码：字体、颜色、间距、以及在不同屏幕上如何重排。传统上改这些细节要么自己写 CSS，要么花钱找人写。WordPress 7.1 把很多这种工作搬到了可视化的界面控件里。

"响应式"就是控制在不同屏幕尺寸下的显示效果：宽屏显示器、平板、手机。7.0 已经允许你按屏幕显示或隐藏页面的某些部分；7.1 更进一步，让你为不同屏幕尺寸设置不同的样式，并且首次让你无需代码就能设置交互状态。所谓"交互状态"，就是访客鼠标悬停、点击、按下时元素的外观——比如按钮悬停变色。

这些交互控件先在部分区块上线，不是一次覆盖全部区块，所以要针对你依赖它们的具体设计元素挨个检查。设计师还能调整"断点"（breakpoints），也就是布局从桌面版切换到平板或手机版的屏幕宽度阈值。

这些控件在哪找：升级之后，在编辑器里打开任意页面，选中一个区块（比如按钮或标题）。右侧设置面板里会看到三个小设备图标：桌面、平板、手机。点击就能为每种屏幕尺寸设置样式，悬停和点击的样式也在同一个面板下。以前请开发者写"移动端 CSS"要花的钱，下次可能就能省下来了。

客户端图片处理是怎么工作的

你往 WordPress 上传一张照片时，通常是在你网站的服务器上完成缩放和压缩的。"客户端"图片处理把这部分工作搬到了上传者的浏览器里——图片在还没发到你的服务器之前，就已经在对方电脑上处理好了。好处是服务器压力更小，同时支持更现代的图片格式。WordPress 7.0 已经为基础缩放引入了这套机制，7.1 把它变成图片处理的默认路径。

Chrome 及基于 Chromium 的浏览器都支持。不支持的浏览器（Firefox、Safari）会自动回落到服务器端处理的老路径，图片质量不受影响，用户体验也不会坏。唯一需要认真测试的是那些在图片上传时做特殊处理的插件。

如果你在意图片版权信息，测试一次上传。照片经常携带隐藏的元数据：摄影师姓名、版权信息、拍摄地点。因为图片处理挪到了浏览器里，升级之后建议上传一张测试图，确认这些隐藏信息还按你期望的方式保留。摄影师、图库用户、以及有版权合规要求的团队尤其要留意。

Notes、图片编辑器、以及两个新区块

WordPress 7.1 新增了两个区块，同时升级了叫 Notes 的协作工具。

Notes（笔记/评论）是你在编辑页面时可以留下的批注，多人协作内容时很有用。7.1 里 Notes 支持：用 @ 符号 tag 特定的人（对方会被自动拉进讨论）、把批注精确挂到某一句话而不是整个段落、多条独立讨论线程、以及批注格式化。另外还有建议模式（suggestion mode）和 emoji 表情回应。如果你就一个人维护网站，可能永远用不到；但如果你和团队或客户协作，这是感受最明显的改动。

第一个新区块是 Playlist（播放列表），一个带声波可视化的音频播放器。如果你发播客、音乐、或者文章的音频版，它替代了原来需要单独装插件才能做的事。

第二个是 Tabs（标签页），把内容组织成可点击的标签，可以在同一个页面上把 FAQ、参数表、评价放到不同的 tab 里，不需要额外工具。

图片编辑器也得到了升级，直接内嵌到页面编辑器里。点击图片上的 Crop 按钮，现在会打开一个专用的编辑窗口覆盖在页面上，取代原来的行内工具。在这个窗口里你可以：拖拽任意形状裁剪，或者吸附到方形、宽屏等预设比例；小步旋转并借助辅助线把歪的照片扶正；翻转图片；编辑图片的详细信息。关闭窗口就回到你原来编辑的位置。目标是让基础修图不再需要另开一个图片应用。

7.1 还给站点品牌信息安了一个自己的家：Appearance → Editor → Identity 下多了一个新的 Identity 屏幕，把站点标题、副标题、Logo、favicon（浏览器标签页上的小图标）集中到一处，可以直接在这个屏幕上编辑。以前这些设置分散在各处，这个改动虽然小，但省了不少翻菜单的时间。

WordPress 7.1 没有什么

网上有不少过时报道，所以先把最重要的一条说清楚：WordPress 7.1 不会移除经典区块。经典区块是那个更简单、更像基础文字处理器的老编辑方式，很多老站还在用。当初真正提出的方案要窄得多——只是把它从区块插入器里藏起来（新增区块时看不到它），现有的经典区块会继续正常工作。而这个方案本身也在 2026 年 7 月 7 日被撤回，什么都不会变。

以下是大家常问、但不在 7.1 里的东西：

• 实时协作编辑没赶上：像 Google Docs 那样两人同时编辑同一页面，还没准备好。这个功能仍在愿望清单上，但还有开放问题，团队这一版把精力放到了 Notes 的升级上。
• 底层大升级被推迟：WordPress 编辑器基于 React 构建，原本预期升级到最新的 React 19，被推迟了。目前只作为开发者实验选项存在，不会默认开启。大多数站长根本感觉不到这个变化。
• AI 的"文风规范"工具没进核心：Guidelines 允许你把编辑规则（语气、偏好用词、要避开的词）一次写好，让 WordPress 记住，不用每次都跟 AI 工具重复。它从 3 月起就作为 Gutenberg 插件的实验功能存在，但 7 月——就在第一个 beta 前 5 天——把它并入 WordPress 核心的提案被否决了，理由是还需要更多真实使用验证。你可以试用，但它不属于 7.1。
• 两个小功能被砍：非英文字符邮箱地址支持，以及"Table of Contents"（目录）区块。都推迟到后续版本。

AI 相关的改动到底有什么？

这一点值得澄清，因为 7.1 在传播中被大量包装成"AI 版本"。你实际能看到、能用的 AI 功能，是在 WordPress 7.0 就已经上线的：AI Client（让插件用统一方式接入 ChatGPT、Gemini 等服务）和 Connectors 屏幕（连接服务商、粘贴 API Key）。这些在 7.0 的指南里已经讲过。

7.1 做的事在这些功能下面一层——Abilities API。可以把它理解成"你的网站能做什么"的一份目录，用软件能读的方式写出来：创建文章、更新产品、修改设置。这个目录已经在过去几个版本里逐步搭建，之所以重要，是因为一个连到你站点的 AI 工具，在能查询这份目录之前，都是在猜。

7.1 让这份目录更易用、更安全：工具可以搜索它，而不是读整份；条目可以标记为"对外开放"或"保持私有"；目录本身用标准格式自我描述，软件不用定制代码就能理解；每次条目被调用时都会跑一组检查点，权限和日志就挂在这里。这些都不是你能点的按钮，但它们决定了未来 AI 工具在你站点上能多安全地工作。

另外两个改动路径相同：WordPress 内置的 AI 代码库现在支持流式响应（不用等完整答案生成完），以及创建 embeddings——这是让搜索理解"含义"而不是匹配"字面词"的技术。这两项都是给插件开发者用的，编辑器本身还没有用到它们。

唯一一处你可能真的看得到的改动：Connectors 屏幕现在除了 API Key，还支持用户名 + application password 的方式接入服务，这是更常见的连接方式，意味着少一个 provider key 要管理。WordPress 同时修掉了浏览器可能把保存的密码自动填到 API Key 字段里的问题。除此之外，7.1 里你会真正点击的部分，都跟设计、媒体、协作有关。

WordPress 7.1 兼容性：升级前该测什么

下面这张表覆盖了每一项改动、影响谁、要测什么：

| 改动 | 影响人群 | 要测什么 | 状态 | |------|----------|----------|------| | 响应式与交互式样式（按屏幕尺寸；悬停/点击状态；无代码） | 设计师、主题作者、代理机构 | 手机和平板上的显示效果，悬停/点击样式是否正常 | 已确认 | | 客户端图片处理 | 图片密集型站点、图片类插件、主机 | 自定义图片尺寸、格式转换、任何图片上传插件 | 已确认 | | 编辑器改在密封 frame 中加载（block 主题） | 有自定义区块的站点 | 自定义区块（需要 Block API v3）、编辑器样式、扩展面板 | 已确认 | | 内嵌图片编辑器（裁剪、旋转、编辑信息） | 内容与编辑团队 | 在编辑器里裁剪、旋转、编辑图片详情 | 已确认 | | Notes 升级（@提及、精确文本批注、线程、格式化） | 编辑与内容团队 | 提及、线程、评论权限 | 已确认 | | Playlist 和 Tabs 区块 | 目前用插件实现这两类功能的人 | 音频播放器与标签面板 | 已确认 | | 工具栏与配色方案在各编辑器间保持一致 | 所有编辑器用户 | 工具栏和配色是否延续到 Site Editor | 已确认 | | 新的自定义图标集注册方式 | 主题与插件开发者 | wp_register_icon_collection()、图标文件安全检查 | 已确认 | | React 19 升级（编辑器底层） | 仅开发者 | 仅实验选项，不要依赖 | 仅实验性 | | 实时协作编辑 | 团队 | 无需测；不要计划生产使用 | 仅在路线图 | | 从插入器隐藏经典区块 | 经典区块用户 | 无需测；仍在插入器中 | 不会执行 | | 目录区块；非英文邮箱 | 无 | 7.1 都不发布 | 不在 7.1 |

如果你运行标准 WordPress 站点（大多数人）

如果你的站点用的是 WordPress 标准区块，主题是常规更新的，那 7.1 就是低风险更新。你会真正感受到的改动都是好的那类：更好用的 Notes、新的裁剪/旋转图片工具、Tabs 和 Playlist 区块。在 staging 副本上升级，走一遍日常的写文章、发布流程，再检查一下你用来做标签页或音频播放的插件是否和新的内置区块和平共处。

如果你为他人设计 WordPress 站点

如果你自己做站或者做深度定制，先用你现有的作品测试新的设计控件。可调断点确实是重大改进，但也可能改变你精心调过的移动端布局的显示效果。打开主要的页面模板，在桌面、平板、手机三种宽度下都看一遍，确认按钮的悬停和点击效果没走样，跟升级前对比一下。

如果你的站点有自定义区块或功能

如果你请了开发者，这一节转给他们看；如果你的站点做过定制功能，这一节慢慢读。有两处改动承担了 7.1 主要的兼容性风险，而几乎没别的文章提到它们。

第一处：编辑器加载方式的改动。对现代"block 主题"来说，编辑器现在会在一个密封 frame 里加载，有点像"窗口中的窗口"（开发者叫 iframe）。用老版本 Block API（v2）构建的自定义区块，需要升级到 v3，否则升级之后可能显示错乱。这是编辑器突然看起来不对的最常见原因。

第二处：涉及在图片上传时做事的插件——特殊缩放、加水印、生成自定义尺寸。因为图片处理搬到了浏览器里，这些插件依赖的技术接入点（开发者叫 hooks）可能不再按原来的方式触发。任何碰图片上传的插件都需要在升级后做一次上传测试。这是自定义站点最容易被绊倒、也最容易被漏掉的一处——因为它只在真正有人上传文件时才会暴露。另外给开发者一句提醒：新 Tabs 区块的内部 data store 在最后清理阶段被移除了，先不要基于它构建任何东西。

不确定 block 主题的改动是否适用于你？这里有个 10 秒钟的检查：进 WordPress 后台，打开"外观"（Appearance）菜单。如果看到"编辑器"（Editor，有时叫 Site Editor）选项，说明你在用 block 主题，编辑器加载方式的改动跟你有关；如果只看到"自定义"（Customize）而没有"编辑器"，说明你在用经典主题，这个担心可以完全跳过。这一个检查决定了本节一半内容是否与你相关。

如何安全测试 WordPress 7.1

WordPress 7.1 升级前的黄金规则：在 staging 站点上测试，永远不要在线上站直接升级。staging 是你站点的私有副本，可以在上面尝试升级、把东西弄坏、再修好，全程没有任何访客看得到。

在 SiteGround 上，你可以在 Site Tools 面板里一键创建 staging 副本，在副本上跑升级，确认满意之后再一键推到线上。

要把 7.1 的预发布版本装到副本上，最简单的路径是装一个免费插件 WordPress Beta Tester：安装后选择"Bleeding edge"选项，它会把最新的测试版本推给你。如果你只想快速看一眼新功能、完全不动自己的站点，可以用 WordPress Playground——它在你的浏览器标签页里跑一个临时的、用完就丢的 WordPress，不用装任何东西、也弄不坏任何东西。Playground 用来参观，真正的 staging 副本用来做正式的兼容性测试。

结论

对大多数人来说，WordPress 7.1 是一次安全、值得升级的版本；如果你在做 WordPress 建站或设计，那这次改动真的很好用——新的设计控件把日常工作里的一大块代码活儿拿掉了。

唯一需要谨慎的场景很窄：如果你的站点有自定义功能，或者用插件对图片做特殊处理，升级前先在 staging 副本上测这些。其他人只需要快速检查一下站点仍在工作即可。

安全路径一直是同一条：备份 → 在副本上测试 → 再真正升级。如果你觉得这些都自己扛太累了，SiteGround 的 WordPress 托管带一键 staging 和自动升级（出问题可以自动回滚），把升级日的压力卸掉，让你能安心地试 WordPress 7.1，觉得可以了再上线。

常见问题

WordPress 7.1 什么时候发布？

计划于 2026 年 8 月 19 日、WordCamp US 凤凰城闭幕当天发布。官方时间表上仍标为"暂定"，如果 RC 阶段发现严重 bug 可能会推迟。

要不要一发布就升级到 7.1？

线上站不要在发布日直接升级。先在 staging 副本上测试——尤其是当你有自定义区块、深度定制的主题、或处理图片上传的插件时。测试通过之后再升级线上站。如果你的站点托管在 SiteGround，请在发布日之前就想好，而不是之后：默认情况下 SiteGround 的 WordPress Autoupdate 工具会在大版本发布 24 小时后自动安装，并在升级前立刻做一次完整备份。你可以在 Site Tools → WordPress → Autoupdate 里延长延迟、跳过某个版本，或者更早升级。

WordPress 7.1 会不会把我的插件和主题弄坏？

对使用标准区块 + 及时更新主题的站点来说，绝大多数不会。真正的风险在两处：用老 Block API v2 构建的自定义区块需要升级到 v3；处理图片上传的插件，因为浏览器端图片处理改变了它们部分接入点的触发时机。

WordPress 7.1 会移除经典区块吗？

不会。7.1 不移除经典区块，而且移除从来没被正式提议过。之前较窄的一个方案（把它从区块插入器里藏起来）已在 2026 年 7 月 7 日被撤回，经典区块继续存在、继续按原样工作。

WordPress 7.1 包含实时协作或 React 19 吗？

不包含正式版。实时协作仍在路线图上、还有未解决问题；React 19 升级被推迟，只作为开发者实验选项回归。这一版的协作方向的工作，都投到了 Notes 的升级上。

WordPress 7.1 是怎么在浏览器里处理图片的？

WordPress 7.1 的客户端图片处理会在访客浏览器中（Chrome 系浏览器）完成图片准备工作——压缩、缩放、格式转换都在上传前完成。不支持的浏览器会自动回落到旧的服务器端处理方式，功能不受影响。