不是所有的WP代码都是公共代码，如果你要发布一些公共的东西，那么所有的东西kovshenin 所说的完全正确。

如果要为自己或公司编写私有代码，情况就不同了。

外部对象缓存是一个很大的好处，在任何情况下，设置外部持久对象缓存very recommended, 当你可以的时候。

kovshenin在回答中所说的关于瞬态和MySQL的所有事情都是非常真实的，考虑到WP本身和一堆插件都利用了对象缓存。。。那么，您所获得的性能改进，绝对值得（少量）建立一个像Redis或Memcached这样的现代缓存系统。

缓存的值可能不存在：这很好，而且，是的，外部对象缓存not 可信赖的你永远不应该相信有一个短暂的存在。如果缓存的位置不在应该的位置，则需要确保它正常工作。

缓存不是存储，缓存是缓存。

有选择地使用缓存参见以下示例：

function my_get_some_value($key) {
   // by default no cache when debug and if no external object_cache
   $defUse = ! (defined(\'WP_DEBUG\') && WP_DEBUG) && wp_using_ext_object_cache();
   // make the usage of cache filterable
   $useCache = apply_filters(\'my_use_cache\', $defUse);
   // return cached value if any
   if ($useCache && ($cached = get_transient($key))) {
     return $cached;
   }
   // no cached value, make sure your code works with no cache
   $value = my_get_some_value_in_some_expensive_way();
   // set cache, if allowed
   $useCache and set_transient($key, $value, HOUR_IN_SECONDS);

   return $value;
}

在您的私有站点中，使用这样的代码可以提高站点性能a lot, 尤其是如果你有很多用户。

请注意：

默认情况下，调试打开时不使用缓存，因此希望在您的开发环境中使用。相信我，缓存会让调试变成地狱。默认情况下，如果WP未设置为使用外部对象缓存，则也不会使用缓存。这意味着与MySQL相关的所有问题都不存在，因为您在使用MySQL时不使用瞬态。一个可能更容易的选择是使用wp_cache_* functions, 所以，如果没有设置外部缓存，那么缓存发生在内存中，而数据库永远不会涉及

缓存的使用是可过滤的，要处理某些边缘情况，您可能会遇到没有网络规模的情况，如果没有缓存，则不应尝试解决缓存的速度问题。如果您有速度问题，那么您应该重新考虑您的代码。

但要在webscale上扩展网站，缓存是非常有用的required.

而且很多时候（但并非总是）片段化、上下文感知缓存比主动式全页缓存更加灵活和合适。

您的问题是：

我应该在这里使用瞬态API吗？

It depends.

您的代码是否消耗了大量资源？如果没有，可能不需要缓存。正如所说，这不仅仅是速度的问题。如果您的代码运行速度很快，但需要一堆CPU和内存供几个用户使用。。。当您有100或1000个并发用户时会发生什么情况？

如果你意识到缓存是个好主意。。

。。。这是公共代码：probably no. 您可以考虑有选择地缓存，就像我上面在公共代码中的示例一样，但如果将此类决策留给实现者，通常会更好。

。。。并且是专用代码：very probably yes. 但即使对于私有代码，有选择地缓存仍然是一件好事，例如对于调试。

无论如何，记住wp_cache_* 函数可以让您访问缓存，而不会有污染数据库的风险。

我应该使用瞬态API缓存$related\\u posts数组还是$html\\u输出字符串？

It depends 在很多事情上。绳子有多大？您正在使用哪个外部缓存？如果要缓存帖子，将ID存储为数组可能是一个好主意，通过ID查询大量帖子非常快。

《最后的注释》瞬态API可能是WordPress最好的东西之一。由于您可以为任何类型的缓存系统找到插件，它成为了大量可以在引擎盖下工作的软件的一个愚蠢的简单API。

在WordPress之外，很难找到这样的抽象，它可以与一系列不同的缓存系统一起开箱即用，并允许您毫不费力地从一个系统切换到另一个系统。

你很少能听到我说WordPress比其他现代的东西更好，但当我不使用WordPress时，瞬态API是我错过的为数不多的事情之一。

当然，缓存很难，不能解决代码问题，也不是一个灵丹妙药，但它是你需要的东西need 建立一个高流量的网站。

WordPress使用未经优化的MySQL表进行缓存的想法非常疯狂，但仅仅因为WordPress在默认情况下进行了缓存，就让自己远离缓存并不是更好的选择。

你只需要了解事情是如何运作的，然后做出选择。

之前的回答已经强调了“必修课”It depends.“，对此我完全同意。

不过，我想添加一条建议，根据我“假设”的方式，这最好在您上面描述的场景中完成。

在这种情况下，我不会使用瞬态，而是使用后Meta，因为后者有一个优点：Control.

由于需要按每篇文章缓存数据，因此要缓存的数据量取决于文章的数量，并且会随着时间的推移而增长。一旦超过一定数量的帖子，您可能会达到对象缓存允许使用的内存限制，并且它将在过期之前开始从内存中擦除以前缓存的数据。这可能会导致这样一种情况，即您有大量的访问者涌入，每个访问者都会在每个页面请求时触发“过于复杂的SQL”，您的站点将完全陷入困境。

如果将数据缓存在Post Meta中，则不仅可以控制数据的存储和检索方式，还可以精确控制数据的更新方式。您将为此添加一个cron作业，该作业仅在站点流量较少或没有流量的时间段运行。因此，网站的真正用户永远不会遇到“慢查询”，您甚至可以预加载它，这样当第一个访问者点击时，工作就已经完成了。

请记住，所有缓存都是一种权衡！这就是为什么通常的答案是“视情况而定”以及为什么没有“圣杯”。