学习wordpress的定制器对象Customizer Objects中，定制器对象的值可以选择保存为两种类型：选项和主题修改项，两者保存的位置不同，选项直接存储在WordPress数据库的wp_options表中，并应用于站点，而不考虑活动主题。主题应该尽可能少的添加选项类型的设置。另一方面，主题修改是特定于特定主题的。大多数主题选项建议选择theme_mods。例如，自定义CSS插件可以将自定义主题css设置注册为theme_mod，允许每个主题具有唯一的CSS规则集，而不会在切换主题然后再切换回来时丢失CSS。
保存在选项中的值，可以使用get_option()函数获取，而保存在主题修改项中的值，则需要用到get_theme_mod（）函数。
在wordpress.stackexchange.com站点上看到了这样一个问题（机翻见谅）：
我一直在用get_theme_mod() 在我的各种项目中有一段时间。我决定利用WordPress v3. 4中的主题定制API，一旦它可用，因为我觉得它是我的客户使用的不可或缺的工具。 过了一段时间，我开始注意到我的站点比平时更慢了，特别是Customizer需要很长时间来加载。在我的调查过程中，通过大量的试验和错误，我决定尝试将type 注册我的设置时（即$wp_customize->add_setting()）从theme_mod 至option。 一旦我这样做了，并交换了我所有的get_theme_mod() 呼叫get_option()，我注意到一非常显著 在前端使用后一种设置，特别是在后端的定制器中，相对于前一种设置，速度会有所提高。我一直在浏览WordPress核心，试图找出原因，但似乎无法辨别这种情况下的具体问题。 机构群体对以下方面的任何见解get_option() 执行速度明显快于get_theme_mod() 将不胜感激。
高赞答案
答案是肯定的，theme_mod函数会变慢，但不是很明显，好处大于区别。
主题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 options调用，然后再进行另一个get_option 调用以再次获取主题名称，然后它会update_option 这会导致数据库更新，而发送更多数据的事实可能确实是速度明显减慢的原因。更新几个字节比更新更大的行要快。但通常不会像你注意到的那么快。除非你有很多设置...
当然，主题mod函数可能需要进行整体优化，但你仍然应该使用它们，而不是get_option等，因为子主题。
直接使用选项行的问题是，您直接使用它们，并对设置使用特定的键名。
如果我有一个名为“AAA”的主题，并且我将它的子主题命名为“BBB”，以便在另一个网站上使用，那么我的“AAA”主题可能会使用名为“example”的选项。当我更新一个网站时，它会更新我的选项，那么相同的选项现在将应用到我的子主题。如果我不希望它这样做呢？如果我希望子主题使用一组不同的选项设置呢？
主题模组，通过包含实际的主题名称（而不是硬编码值）作为键的一部分，确保网站上的每个“主题”都使用自己的设置。我可以来回切换，设置不会在它们之间转移，它们保持我设置它们的方式。更简单，更明显，更直观。
如果将来有一些核心的改变或者插件修改了theme_mods的工作方式，那么你将自动地得到它的好处，而不需要任何改变。包装器总是会变慢，这是不可避免的，这是包装器的本质。然而，你仍然在写PHP代码，而不是机器语言。我们使用这样的包装器来简化事情和分离功能。主题不应该知道，或者关心。他们的选项是如何存储在数据库中的，或者命名是如何工作的。theme_mod函数提供了一个更简洁的解决方案。
