问题描述
我一直在使用 get_theme_mod()一段时间在我的各种项目。我决定在 WordPress v3.4 中使用主题自定义 API，因为我觉得这是我客户使用不可或缺的工具。
过了一段时间，我开始注意到我的网站比平常感觉有点迟钝，而且定制器特别需要相当长的时间来加载。在调查过程中经过大量的尝试和错误，当我将设置 ($wp_customize->add_setting()) 从 theme_mod 注册到 option 时，我决定尝试关闭 type 。
一旦我做到了这一点，并把我所有的 get_theme_mod()调用换成 get_option()，我注意到使用后一种设置，而不是在前端，特别是在后台定制器上，速度显著提高。我一直在浏览 WordPress 核心，试图找出一个为什么这样做的答案，但似乎无法辨别这种情况下特定的挂起是什么。
get_option()的 get_theme_mod()性能明显快于 get_theme_mod()所能获得的任何见解将不胜感激。
最佳解决方案
答案是肯定的，theme_mod 的功能会更慢，但不是很明显，而且效益大于差异。
主题模式存储为选项。因此，实质上，theme_mod 功能是选项功能周围的包装器。
首先，了解 theme_mod 设置是作为一个数组存储在一个选项中，键入特定的主题名称。所以，如果我这样做：
set_theme_mod('aaa',123);
set_theme_mod('bbb',456);
那么我在数据库中实际获得的是一个名为 theme_mods_themename 的单个选项行，它包含一个带有 (‘aaa’ => 123，’bbb’ => 456) 的序列化数组。
现在，get_theme_mod 将会更慢，因为它实际上正在进行两个 get_option 调用。首先，它得到主题的名称。然后，它获得 theme_mods_themename 选项。那么那就是 50％的速度损失。完成的其余工作主要在于过滤器，因为有一个额外的过滤器调用，但是除非您在该过滤器上有某些内容，否则这并不重要。
请注意，选项系统将检索到的数据存储在对象缓存中，因此在此处不会进行多个数据库调用。只有第一次使用导致数据库命中。
set_theme_mod 会稍微慢一点，因为它使得两个相同的选项被调用，那么它再次创建了一个 get_option 调用来获取主题名称，然后它就是 update_option 的全套现在更改的选项。这导致数据库更新，并且发送更多数据的事实确实可能是导致显著减速的原因。更新几个字节比更新更大的行更快。但是，通常不会像你注意到的那么多。除非你有很多设置的整体…
主题 mod 函数可能是为了优化整体而言，但是，但是您仍然应该使用它们而不是 get_option，因此是由于子主题。
直接使用选项行的问题是您直接使用它们，并使用特定的密钥名称进行设置。
如果我有一个名为”AAA” 的主题，并且我创建一个名为”BBB” 的子主题，以便在另一个站点上使用，那么我的”AAA” 主题可能会使用名为”example” 的选项。当我更新一个网站，并更新我的选项，那么相同的选项现在将适用于我的孩子主题。如果我不想这样做，该怎么办？如果我想让孩子主题使用不同的选项设置，该怎么办？
主题模式，通过包括实际的主题名称 (而不是硬编码的值) 作为密钥的一部分，确保网站上的每个”theme” 使用其自己的一组设置。我可以来回切换，设置不会在它们之间转移，它们会保留我如何设置它们。更简单，更明显，更直观。
如果未来的核心更改或插件修改了 theme_mods 的工作原理，那么您将自动获得其优点，无需任何更改。包装总是慢一点，这是不可避免的，它是包装纸的本质。不过，您仍然在编写 PHP 代码，而不是机器语言。我们使用这样的包装器来简化和分离功能。主题不应该需要知道或关心他们的选项如何存储在数据库中，或者命名如何工作。 theme_mod 功能提供更简单的更清洁的解决方案。
参考文献
注：本文内容整合自 Google/Baidu/Bing 辅助翻译的英文资料结果。如果您对结果不满意，可以加入我们改善翻译效果：薇晓朵技术论坛。