实际上，对菜单执行此操作很好，您甚至可以存储整个HTML输出，并且不仅可以减少查询，还可以减少处理时间。此外，您可以将WP\\u Object\\u Cache直接与Redis/Memcached后端结合使用，甚至可以避免瞬态本身的单个DB查询。

重新评论——它们确实会改变，因此运行WP_Comment_查询是不可避免的。但是，您也可以在短时间内缓存它们。比如说，5分钟。在这种情况下，在用户看到他们的新评论之前，您需要在速度提升和延迟之间找到平衡。

经验法则是，在需要时缓存，当它给您带来积极影响而不会带来负面影响时。

WordPress在缓存最重要的东西（包括菜单项）方面已经做得很好了——只需将对象缓存类放在WP内容中，并在服务器上添加对象缓存后端。

在做了几个月之后，我相信我最初的问题是有充分根据的，虽然这项技术肯定不是新技术，但我正在做的是极大地优化我的系统中的许多东西：

（这更具哲理，但我会提供代码）

我不打算讨论一个大家都能理解的事实，即您不应该临时处理会影响工作流程的项目/查询，也不应该临时处理所有内容，因为这会使数据库超载，尤其是在有大量大型查询的情况下——例如，在一个不太好的主机上，将每个用户的帖子（假设你有一个大社区）成群结队地转移是一个很大的禁忌。你可能有一些非活动用户，每个用户都有10-15篇帖子，但没有人去他们的页面，所以他们的数据在数据库中只会保持空闲，just waiting for someone to access it to reset. （这可以通过在该用户的页面上创建瞬态来解决，希望您已经在这样做了！）

不管that\'s exactly how we must do it: Instead of thinking of transients in terms of expire-on-time, we should approach them from a expire-on-trigger way.

因此，不是：

set_transient( \'name\', \'value\', 3600 );

add_action( \'save_post\', function( $post_id, $post, $update ) {
    $author = get_post_field( \'post_author\', $post_id );
    /**
     * But if he is, then we\'ll delete his posts\' transient.
     */
    delete_transient( \'user_posts_\' . $author->ID );
});

现在，当有人点击该用户的页面而不在计时器上时，将重新创建该瞬态。

唯一的问题是数据库现在变得越来越大，因此我们需要一种垃圾收集机制，它不会保留数据库中不“流行”的瞬态，因此我们不会将其弄乱。

我已经成功地将其应用于与媒体库图像相关的瞬态，在那里我需要一个瞬态，但我也希望有一个触发器来更新它。

完成这一点后，我越是关注这一点，我就越认为这应该被称为“知道何时需要更新瞬态”。

到目前为止，它为我解决了比它造成的问题更多的问题，但我同意，这是否能很好地扩展还不确定。同时，需要扩展的问题是一个需要解决的重大问题，如果您以这种方式对系统进行编码，只需断开这些删除机制，它就可以以传统方式工作。

So, exactly what has this helped me achieve? What are the benefits?

事实上，删除某个触发器上的瞬态比删除计时器上的瞬态更有意义。