問題描述
我一直在使用 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 輔助翻譯的英文資料結果。如果您對結果不滿意，可以加入我們改善翻譯效果：薇曉朵技術論壇。