WordPress 6.1 REST API 性能优化详解

WordPress 6.1 对 REST API 进行了重大升级，通过多项关键优化显著提升了性能表现。这些改进的核心目标在于减少每个 API 请求中数据库查询的次数，从而实现更高效的资源调用。

### 避免不必要地准备项目链接

在 WordPress 6.1 发布之前，REST API 的所有控制器都会默认调用 prepare_links 方法。这种设计存在明显缺陷：当请求中未包含 _fields 参数时，链接字段将不会被请求，自然也无法在响应中返回。尽管如此，prepare_links 方法仍会执行，其中可能包含数据库调用或其他复杂逻辑，即便这些操作永远不会触发响应。这种设计无疑造成了资源浪费。

WordPress 6.1 对此进行了彻底优化。prepare_links 方法现在仅在响应中明确请求链接字段（_links）或嵌入内容（_embedded）参数时才会被调用。这一改进要求分类和文章类型控制器进行同步更新，以符合新的设计规范。以下是实现这一变更的代码示例：

**变更前：**
“`php
$response = rest_ensure_response( $data );
$links = $this->prepare_links( $post );
$response->add_links( $links );
return $response;
“`

**变更后：**
“`php
$response = rest_ensure_response( $data );
if ( rest_is_field_included( ‘_links’, $fields ) || rest_is_field_included( ‘_embedded’, $fields ) ) {
$links = $this->prepare_links( $post );
$response->add_links( $links );
}
return $response;
“`

新的逻辑确保只有在请求中明确包含 _links 或 _embedded 字段时，才会执行 prepare_links 方法，大幅减少了不必要的数据库操作。

### Posts 控制器的改进

通过分析 REST API 响应数据，开发团队发现 posts 控制器在处理每个帖子请求时会产生大量冗余的链接数据。例如，在返回文章时，系统会自动包含作者（用户）、特色图像和父帖子等所有相关链接。由于这些链接数据未在缓存中预准备，每个帖子请求都可能触发多达 3 次独立的数据库查询：一次查询用户信息，一次查询特色图像，另一次查询父帖子。

WordPress 6.1 通过引入新的缓存优化机制解决了这一问题。所有相关缓存现在都在单个数据库查询中启动，显著减少了查询次数。核心改进包括：

– **update_post_author_caches**：通过单个查询获取一组帖子并同步用户缓存。
– **update_post_parent_caches**：在单个查询中同时获取帖子和父帖子数据。
– **update_menu_item_cache**：通过单个查询获取一系列帖子，并将帖子/术语链接到菜单项。
– **update_post_thumbnail_cache**：继续使用现有函数优化特色图像缓存。

这些优化不仅提升了 posts 控制器的性能，还将推广至 WordPress 内核的其他部分，为更多组件带来缓存启动的效率提升。

### 对其他控制器的改进

除了 posts 控制器，WordPress 6.1 还对其他核心控制器进行了性能优化：

– **用户控制器**：现在在单个查询中启动用户元数据，大幅减少数据获取开销。
– **评论控制器**：通过单次查询优化链接帖子的缓存机制。
– **搜索后控制器**：针对搜索请求进行了数据库性能优化。
– **媒体控制器**：改进了媒体资源的数据处理流程。

这些改进共同推动了 WordPress REST API 整体性能的飞跃，为开发者提供了更高效、更稳定的接口体验。

更多技术细节请参考 Trac 工单：#52992、#56019、#56020、#55592、#55593、#55620、#55674、#56272、#55677、#55716。

文章网址：https://www.wpbull.com/news/2005.html