打開 WordPress 文章編輯畫面，你想幫某個商品多存一個「保固年限」欄位，翻遍區塊編輯器的每個面板都找不到，最後在畫面右上角的「選項」裡勾出「自訂欄位」，跳出來的卻是兩個空白輸入框，一個打「鍵」，一個打「值」，全部手動輸入，格式對不對、有沒有打錯字，系統完全不管。下次換另一個同事來填，他打成「保固期限」，兩筆資料從此各過各的，怎麼撈都對不起來。
WordPress 核心確實內建自訂欄位（Custom Fields，技術上叫 post meta）這項功能，但介面停在最原始的狀態：純文字輸入，沒有型別，沒有驗證，也沒有清楚的位置規則可以決定這組欄位該出現在哪種內容底下。Advanced Custom Fields（ACF）要解決的正是這個落差，把 WordPress 原生就有的自訂欄位機制，包裝成一套有型別、有驗證、有版面配置的後台介面，讓「多存一個欄位」這件事不必再靠純手打，也不必自己寫程式碼刻後台輸入框。目前這支外掛的活躍安裝數超過 200 萬，評分落在 90%（五顆星裡的 4.5 顆），在自訂欄位這個工具類別裡是市佔最高的一支，不是小眾外掛。
ACF 是什麼？把原生自訂欄位包成好用的介面
從介面往下拆一層看，ACF 具體做的其實是三件事。第一、把「新增欄位」這個動作從程式碼搬進後台圖形介面，用滑鼠點選就能建立一個文字、圖片或關聯欄位，不必碰任何 PHP。第二、每種欄位都帶著對應的資料型別與驗證規則，Email 欄位會擋掉不是信箱格式的輸入，Number 欄位可以設最小值與最大值，這是原生 key/value 輸入框完全做不到的。第三、前台顯示交給一組固定的範本函式，開發者不必自己寫程式碼去讀 postmeta 資料表、判斷這筆資料存的是字串還是陣列。
完全不裝外掛也做得到同樣的效果，只是要自己動手寫add_meta_box()這個 WordPress 函式，手刻後台輸入介面、自己處理驗證邏輯與資料儲存。多數網站選擇 ACF 而不是自己刻的理由很直接，同樣的效果，用點選介面幾分鐘就能完成，換成寫程式碼常常要花上幾個工作天，還得自己顧資安與相容性。
市場上另外還有一個 ACF PRO 付費版本，差在中繼器、彈性內容這類進階欄位型別與選項頁。安裝免費版不需要額外下載任何檔案，登入 WordPress 後台，「外掛」→「安裝外掛」，搜尋「Advanced Custom Fields」，找到官方這一支點下「立即安裝」再啟用即可，它本來就在 WordPress.org 官方外掛目錄上架。
建立欄位群組與位置規則，決定欄位出現的位置
欄位不會憑空出現在編輯畫面上，得先幫它們找一個容器跟一條規則。ACF 把這個容器叫做欄位群組（Field Group），你在裡面放進一個或多個欄位，決定它們的順序與版面；至於這個群組該出現在哪個後台編輯畫面，則由位置規則（Location Rules）決定。兩者搭配起來，才會讓「保固年限」這種自訂欄位精準只出現在該出現的地方，而不是每篇文章、每個頁面都跳出來。
位置規則由三個要素組成：位置型別、比對運算子、值。ACF 官方文件把它定義得很直接，位置規則用來決定欄位群組出現在哪個管理畫面，由位置型別、比對運算子與值組成，舉例來說「文章類型 等於 文章」就是一條最基本的規則。免費版可以拿來當位置型別的選項不少：文章、頁面、自訂文章類型、使用者、分類法詞、媒體、留言、選單都在列，換句話說，不只是文章跟頁面，連新增一個使用者、上傳一張圖片時的編輯畫面都能掛上自訂欄位。
一個欄位群組不限只能設一條規則，可以疊加多條，規則之間可以是「而且」也可以是「或者」的關係，例如「文章類型等於文章，而且分類等於品牌行銷」，就能做到只在這個分類底下的文章才出現這組欄位的精細控制。免費版可以設定的位置型別裡還有一種是選項頁（Options Page），一個網站層級、不綁定任何單篇內容的獨立設定頁面，不過它是 PRO 版才有的位置類型，免費版建立不了。
基礎文字與數字欄位，涵蓋七種最常見的輸入格式
官方欄位類型頁把最常用的純文字與數字輸入歸在同一個分類，稱作「Basic」，一共 7 種，全部免費版可以直接用，不需要加購 PRO。差異多半在要輸入什麼樣的資料、要不要驗證格式，尤其是最容易搞混的兩組：Text 跟 Text Area、Number 跟 Range。
Text 存放型號、標題這類一行短文字
Text 是最基礎的單行文字輸入框，適合存副標題、簡短標籤、產品型號這類一行寫得完、不需要換行的內容。它跟 WordPress 原生自訂欄位的差別，不在能不能輸入文字（原生輸入框本來就能打字），而在於 ACF 版本可以在建立欄位當下就設定字元上限、預設值跟版面上的說明文字，原生輸入框完全沒有這些設定選項。
實務上這是用量最大的一種欄位型別，原因很直接，多數自訂資料本來就是短文字。要注意的是它跟下面的 Text Area 分工清楚，只要內容可能超過一行、或需要保留換行，就該換用 Text Area，硬把長文字塞進 Text 欄位，存進資料庫的雖然不會出錯，但編輯畫面的輸入框會被撐得又長又難編輯。
Text Area 是 Text 的多行版本，允許換行
Text Area 是 Text 的多行版本，拿掉了單行限制，適合放摘要、簡介、注意事項這類篇幅較長，但仍然是純文字、不需要加粗體或超連結格式的內容。介面上它比 Text 欄位長，允許自然分段換行，存進資料庫的仍然是一整串沒有格式標記的文字。
拿捏該用 Text 還是 Text Area，判斷標準很簡單，只看內容長度跟要不要換行，不看內容重不重要。一句話的商品副標題，就算再重要也還是用 Text；三、五句的介紹文字，就算內容普通也該用 Text Area，不然編輯者打字打到一半才發現框太小，操作起來綁手綁腳。
Number 限制輸入格式，不接受非數字字元
Number 欄位把輸入限制成數字，格式不對，比如打進中文字或符號，直接會被擋下來，不能儲存。欄位設定裡還可以加最小值、最大值，甚至遞增值（每次用上下箭頭調整的間距），這對「保固年限」、「庫存數量」這類本來就該落在合理範圍內的資料特別有用，能在資料一進來的第一關就擋掉離譜的輸入。
沒有這層驗證的原生自訂欄位，常見的狀況是編輯者手殘多打一個空格、或不小心輸入成文字，前台程式在讀取這筆資料做數學運算時直接出錯，而且往往要等到網站真的壞掉才會被發現。Number 欄位等於是把這個風險擋在後台輸入的當下，而不是等前台顯示時才爆出來。
Range 用可拖曳的滑桿取代打字輸入
Range 存的資料型態跟 Number 完全一樣，都是數字，差別純粹在輸入介面，Range 用一支可以拖曳的滑桿取代打字框，適合評分、進度、完成度這類本來就有明確上下限、而且拖曳比打字更直覺的數值。
挑 Number 還是 Range，判斷點在使用者體驗上拖曳滑桿比打數字更順手嗎。一到十的滿意度評分，用滑桿讓人一眼看出目前落在哪個區間，比打一個阿拉伯數字進去更有感；但像「保固年限」這種有明確單位、編輯者心裡早就有答案的數字，直接打字反而比拖滑桿找到那個刻度更快。
Email 即時檢查是不是合法信箱格式
Email 欄位在輸入當下就會即時驗證是不是合法的信箱格式，格式不對，少了「@」符號或網域，系統就直接擋下，不讓你儲存。這比原生自訂欄位的純文字輸入多了一層資料品質保障，尤其是收集聯絡資訊、報名資料這類場景，一筆打錯的信箱地址，後續要人工回頭抓漏遠比一開始就擋下來麻煩。
要留意的是，Email 欄位只驗證格式對不對，不會確認這個信箱真的存在，也不會幫你發送驗證信，它做的是防呆，而不是驗證信箱真實性，兩者是不同層次的事，真要做到後者，得另外串接第三方驗證服務。
URL 只驗證網址格式，不檢查內容
URL 欄位的驗證邏輯跟 Email 相似，差在驗證對象換成合法的網址格式，沒有 http 或 https 開頭、格式不對的輸入一樣會被擋下。適合用來存放外部連結，像是社群帳號網址、參考資料出處，也能拿來存站內某個路徑。
跟後面 Relational 分類要介紹的 Link、Post Object 這類欄位比，URL 欄位存的只是一段網址字串，不會像 Post Object 那樣連到 WordPress 內部真正的文章物件、拿得到標題與精選圖片這些額外資訊。單純只需要一段連結文字時，URL 欄位比較輕量；需要跟站內另一篇內容產生真正關聯時，後面 Relational 分類的欄位會更合適。
Password 遮蔽畫面顯示，資料庫仍存明碼
Password 欄位輸入的內容會以遮蔽字元顯示在畫面上，不會像其他文字欄位那樣把內容原樣攤在螢幕上。適合的情境是後台需要輸入一些不方便被旁人看到、卻又想用 ACF 介面統一管理的資料，例如第三方服務的 API 金鑰、內部系統的存取密碼。
要留意的是，遮蔽顯示只是畫面呈現上打了馬賽克，資料庫裡儲存的方式跟其他文字欄位一樣是明碼，並沒有額外加密，這一點跟真正的帳號登入密碼系統（WordPress 核心會對使用者密碼做雜湊處理）不是同一回事，敏感度真的很高的機密資訊，還是建議走專門的密碼管理機制，不要單靠這個欄位的遮蔽顯示。
選擇型欄位把輸入從打字改成點選
官方分類裡的「Choice」收了 5 種欄位，全部免費版可用，核心邏輯跟前面的 Basic 分類完全不同，不是驗證打進去的文字對不對，而是乾脆不讓編輯者打字，改成從一組預先設定好的選項裡點選。少了打字這個環節，同時也少了打錯字、選項寫法不統一這類麻煩。
這 5 種欄位存的資料型態高度相似，差別集中在畫面呈現方式跟單選複選的預設行為，選哪一種常常是體驗上的取捨，不是功能上的限制。
Select 用收合式選單容納大量選項
Select 是下拉選單，平常收合成一行，點開才展開全部選項，可以設定成單選或複選。適合選項數量比較多，十個、二十個都算常見，又不想讓後台編輯畫面被一長串選項占滿版面的情境。
下拉選單的取捨也很明顯，選項全部藏在收合狀態裡，編輯者要先點開才看得到有哪些選擇，如果選項不多、又希望編輯者一眼掃過全部選項再決定，後面的 Radio Button 或 Button Group 會更合適。
Checkbox 預設就支援一次勾選多項
Checkbox 本來就支援複選，一次勾選多個選項是它的預設行為。欄位設定裡有一個「允許加入自訂值」的開關，打開之後，填寫欄位的編輯者可以自己臨時新增一個原本沒設定過的選項，不必回到欄位群組的設定畫面裡手動加。
這個「允許加入自訂值」的彈性，拿捏上要小心，太開放會讓同一個概念被打成好幾種不同的寫法，原本靠選擇型欄位想避免的輸入不統一問題，又從後門跑回來了。比較保守的做法是選項清單先想清楚、涵蓋到九成以上的情境，自訂值開關留給少數真的無法預先窮舉的例外情況。
Radio Button 把所有選項直接攤開顯示
Radio Button 是單選鈕，所有選項會直接攤開顯示在畫面上，不像下拉選單需要多點一次才看得到。適合選項數量不多，通常在五到八個以內，又希望編輯者能一眼比較所有選擇的情境。
跟 Select 比起來，Radio Button 犧牲的是畫面空間，換來的是不用多點一次的效率；選項一多，攤開的清單反而讓畫面變得又長又亂，這時候還是該換回收合式的下拉選單。
Button Group 用按鈕取代圓形選取鈕
Button Group 存的資料跟 Radio Button 一模一樣，同樣是單選，差別純粹在畫面呈現，用一排視覺化的按鈕取代傳統的圓形選取鈕，點下去的那顆按鈕會直接反白標示，比小小的圓點更顯眼。
這種欄位型別特別適合選項本身就帶有清楚識別色或圖示意涵的情境，例如用顏色或狀態當選項時，按鈕群組的視覺回饋比單選鈕更直覺；純文字選項的情況下，兩者的實際體驗差異就沒那麼明顯，選哪個多半看畫面風格喜好。
True / False 只有是與否兩種值
True / False 是一個開關型欄位，只有「是」與「否」兩種值，存的資料型態最單純。除了直接拿來記錄一個是非狀態，它更常見的用法是當條件邏輯的判斷依據，後面「條件邏輯」那節會講到，用一個 True/False 欄位問「這是不是活動類文章」，勾選之後才顯示一整組跟活動相關的欄位，不勾就整組隱藏起來。
跟 Checkbox 的差別在於，Checkbox 天生就是給多選用的清單，就算清單裡只放一個選項，存的資料結構仍然是陣列；True/False 存的是單一的是非值，結構更輕量，單純只需要一個開關時，選 True/False 比硬把 Checkbox 縮到只剩一個選項更乾淨。
內容型欄位收進圖片、檔案與嵌入媒體
官方分類「Content」底下原本有 5 種欄位，這節只展開講其中 4 種，Image、File、oEmbed、WYSIWYG Editor，全部免費版可用；剩下的 Gallery（相簿，一次管理多張圖片）是 PRO 版才有的欄位。
這一組欄位的共通點是處理的內容都超出純文字範圍，牽涉到媒體庫、外部嵌入或格式化的內容區塊，跟前面純打字或點選的欄位相比，設定選項也相對豐富一些。
Image 可以上傳新圖或選用媒體庫既有圖片
Image 讓編輯者上傳新圖或從媒體庫裡選一張既有的圖片，欄位設定裡可以指定回傳值的格式，是要拿到完整的圖片物件、單純的網址字串，還是媒體庫裡的附件 ID，三種格式在前台程式讀取時處理方式不一樣，依實際需求挑選就好。
除了回傳格式，還能限制預覽尺寸、指定媒體庫來源（例如只能選某個資料夾底下的圖），這些細節設定原生自訂欄位完全沒有，原生做法要嘛得自己刻一個媒體庫選擇器，要嘛只能讓編輯者手動貼圖片網址，兩種都比 Image 欄位麻煩。
File 處理圖片以外的檔案上傳
File 處理的是圖片以外的檔案上傳，PDF、文件、壓縮檔都算，適合放產品說明書、報價單、規格表這類需要附件、但本身不是圖片的內容。
跟 Image 欄位共用同一套媒體庫機制，上傳過的檔案一樣會進媒體庫管理，差別只在於 File 欄位不限制副檔名一定要是圖片格式。實務上常見的用法是產品頁附上一份可下載的 PDF 型錄，或活動頁掛上報名表單的範本檔案。
oEmbed 貼網址就自動抓取嵌入預覽
oEmbed 讓編輯者貼上一段支援 oEmbed 協定的網址，常見的像影片平台、社群貼文，欄位就會自動抓取內容並顯示嵌入預覽，不必手動貼嵌入碼。它用的是 WordPress 核心本來就有的 oEmbed 機制，不需要額外寫解析程式。
這代表它的相容範圍完全跟著 WordPress 核心的 oEmbed 白名單走，只要是核心支援的服務，貼網址就能自動出現預覽；不在白名單裡的來源，則不會自動解析，這時候還是得靠其他方式手動嵌入。
WYSIWYG Editor 儲存的內容是格式化 HTML
WYSIWYG Editor 是所見即所得的富文本編輯器，跟文章正文用的是同一套介面，支援粗體、清單、連結這類格式化功能，儲存下來的內容是一段 HTML，不是純文字。
跟前面 Text Area 的分工很清楚，需要格式化（粗體、項目符號、超連結）的長文字用 WYSIWYG Editor，只是單純長文字、不需要任何格式的說明用 Text Area 就好。選錯的常見後果是把 WYSIWYG Editor 用在不需要格式的地方，前台輸出時反而要多處理一層 HTML 標籤，徒增複雜度。
關聯型欄位讓欄位之間互相指到彼此
官方分類「Relational」收了 6 種欄位，全部免費版可用，處理的是這篇內容跟另一篇內容、某個分類詞或某個使用者之間有關聯這件事。前面幾個分類的欄位存的都是內容本身，一段文字、一張圖，這組欄位存的則是指向另一筆資料的關係，是把散落的文章從各自獨立變成有結構串接的資料庫的關鍵。
6 種欄位的差異多半落在連到什麼類型的目標、介面複雜度這兩點，選型判斷可以照這個邏輯走。
Link 只存網址與連結文字，拿不到文章物件
Link 存的是一段連結，一個欄位就包含網址、連結文字跟是否開新視窗這幾項資訊，比單純的 URL 文字欄位多帶了額外的中繼資料。
適合放在需要一個連結、加上顯示文字跟開啟行為的情境，例如頁尾的外部連結區塊。它跟接下來要講的 Post Object、Page Link 不同，Link 連到的可以是任何網址，不限站內文章，靈活度較高，但也拿不到站內文章物件才有的標題、精選圖片這些延伸資訊。
Post Object 選文章物件，能進一步讀取欄位資料
Post Object 用下拉或自動完成介面選擇另一篇文章或頁面，回傳的是完整的文章物件，不只是一個網址。這代表前台程式讀到這個欄位之後，可以進一步拿到那篇文章的標題、連結、精選圖片，甚至它自己的其他自訂欄位。
常見的用法是這篇文章要指定一篇相關主打文章這類需要進一步讀取目標內容細節的情境；如果只是單純需要一個連結、不需要讀取目標的其他資料，用前面的 Link 欄位反而更輕量，不必多繞一層物件查詢。
Page Link 限定只能連到已發佈頁面
Page Link 跟 Post Object 高度相似，差在專為內部連結設計，多了依文章類型、發佈狀態篩選候選項目的選項，可以只讓編輯者從已發佈的頁面裡挑，擋掉草稿或其他文章類型混進來的可能。
拿捏 Post Object 跟 Page Link 的分界，兩者存的資料結構其實很接近，選 Page Link 通常是因為要更嚴格地限制候選清單的範圍（比如只能連到某個特定文章類型底下已發佈的項目），Post Object 則沒有這層篩選介面上的講究。
Relationship 建立文章之間多對多的關聯
Relationship 是這組欄位裡功能最豐富的一種，用來建立多對多的關聯，一篇文章可以連到多篇其他內容，同時反過來，那些內容也可能各自連到好幾篇不同文章。介面可以依文章類型、發佈狀態、分類篩選候選清單，比 Post Object 的單純下拉選單複雜得多。
適合一篇文章要關聯多篇其他文章的情境，例如把一篇教學文章跟好幾篇周邊延伸的其他文章串起來。跟 Post Object 的差別在於後者天生只設計給單選或簡單複選使用，面對這篇要關聯十幾篇不同性質內容這種需求，Relationship 的篩選介面會讓編輯者找起來輕鬆得多。
Taxonomy 選分類詞，用的是同一套底層資料
Taxonomy 讓編輯者直接在欄位裡選擇分類詞，某種程度上可以取代 WordPress 原生右側欄的分類勾選介面，好處是能把分類選擇搬到欄位群組裡跟其他自訂欄位放在一起，編輯畫面更集中。
它跟 WordPress 內建的分類法系統是同一套底層資料，只是換了一種前台呈現方式與位置，並不是另外新建一套獨立的分類機制，這點容易被誤會，實際上兩者操作的是同一份分類詞資料。
User 把帳號本身跟內容項目做關聯
User 把一位或多位使用者關聯到目前的文章、自訂文章類型項目，或另一位使用者身上，適合這篇內容的負責人是誰、這個項目要指定哪位使用者審核這類需要連結到帳號本身、而不是連結到內容的情境。
跟 Post Object 的差別很直接，Post Object 連的是內容（文章、頁面），User 連的是帳號，兩者處理的是完全不同性質的關聯，不會互相取代。
進階輸入元件涵蓋日期、地圖與顏色選擇器
官方分類把這組欄位歸類為「jQuery」，共 6 種，全部免費版可用。共通點是都靠前端的互動元件，日期選擇器、色票板、地圖選點，取代純打字輸入，把該打成什麼格式這個問題直接從編輯者身上拿走，交給互動元件去產生正確格式。
這組欄位跟 Choice 分類的差別在於，Choice 是從固定清單裡選，這組則是在一個連續的範圍（日期、時間、顏色、地理位置）裡挑一個值，互動方式也更接近視覺化操作而不是勾選。
Color Picker 選色後存成十六進位色碼
Color Picker 是色票選擇器，選色後存成十六進位色碼，適合讓編輯者自訂區塊背景色、強調色這類需要精確色彩資料的欄位。
比起要求編輯者自己記色碼、手動打進文字欄位，色票板讓非技術背景的編輯者也能靠肉眼挑色，不必先懂十六進位色碼的規則，選錯色碼格式導致前台樣式跑掉的風險也一併降低。
Date Picker 顯示格式與儲存格式可以不同
Date Picker 提供一個可以點選日期的小日曆介面，可自訂顯示格式與儲存格式，這兩者可以不一樣，前台顯示可以是易讀的日期格式，資料庫裡實際存的卻是機器容易處理的格式，兩邊各自用各自需要的形式。
這樣的雙軌設計解決了一個原生自訂欄位常見的麻煩，純文字輸入日期時，編輯者可能打成一種寫法、也可能打成另一種寫法，兩種寫法對電腦來說是不同的字串，前台程式排序或篩選時完全對不起來；有了固定的儲存格式，這個問題就不存在。
Date Time Picker 一次選完日期跟時間
Date Time Picker 在日期之外多帶了時間欄位，一次選完日期跟時分，適合活動起訖時間、直播開始時間這類需要精確到分鐘的欄位。
跟單獨的 Date Picker 相比，差別只在多了時間這個維度，操作邏輯完全一樣；真正只需要日期、不牽涉時間的情境，還是用 Date Picker 就好，不必為了保留彈性而預設都用 Date Time Picker。
Time Picker 只選時間，不含日期
Time Picker 只選時間，不含日期，適合營業時間、固定時段這類跟具體某一天無關、只在乎時分的欄位。
這種欄位常被忽略，不少人習慣性都用 Date Time Picker 再把日期欄位晾在那不管，實際上只要情境明確不需要日期，直接用 Time Picker 能讓資料結構更乾淨，前台讀取時也不必多處理一個永遠用不到的日期值。
Google Map 在地圖上點選就存下經緯度
Google Map 整合 Google Maps API，讓編輯者直接在地圖上點選位置，欄位存下的是經緯度座標。要讓地圖真的顯示出來，得先自行申請 Google Maps API 金鑰，並填進 ACF 的全域設定裡，這是它跟前面幾種欄位最不一樣的地方，其他欄位裝好外掛就能用，這個欄位還多一道申請金鑰的手續。
沒填 API 金鑰的情況下，欄位設定畫面會提示需要金鑰，地圖介面也顯示不出來，這是實際上手時最容易遇到問題的環節，值得在導入前先確認好這道申請流程，免得建好欄位群組才發現地圖是一片空白。
Icon Picker 挑圖示，內建 Dashicons 圖示庫
Icon Picker 讓編輯者從一組圖示庫裡挑選圖示，內建 WordPress 本身的 Dashicons 圖示庫可以直接選，也支援上傳自訂的圖示檔案。
適合需要在前台某個區塊搭配小圖示、又不想每次都手動去媒體庫上傳單一小圖的情境，例如服務項目列表旁邊配一個對應的圖示，用這個欄位挑選比每次上傳、裁切一張新圖片快得多。
版面欄位把落落長的欄位群組收整齊
官方分類「Layout」共 6 種，這節展開的是免費版可用的 3 種，Accordion、Tab、Group；另外 3 種 Clone、Flexible Content、Repeater 是 PRO 版專屬。這組欄位有個共通特性，跟前面所有欄位都不一樣，它們本身不儲存任何新資料，純粹是後台編輯畫面的整理工具。
一個欄位群組裡放到十幾、二十個欄位是很常見的事，如果全部攤平顯示，編輯畫面會變成一長串輸入框，得不斷往下捲動才找得到要改的那一項。版面欄位解決的正是這個問題，欄位一多才看得出差別，欄位少的群組不太需要用到它們。
Accordion 把接續欄位收進可展開的面板
Accordion 把接續在它後面的欄位收進一個可以展開、摺疊的面板，常見用法是欄位一多就分幾組區塊，平常收合起來，編輯者需要改哪一組才點開哪一組，不必面對一次全部攤開的長頁面。
這種收合機制對有些欄位不常改動的情境特別有幫助，把不常用的欄位群組收進摺疊面板，常用的留在最上面攤開，編輯者打開文章編輯畫面時第一眼看到的就是真正常改的內容，不會被一堆不相干的設定選項淹沒。
Tab 用頁籤分頁顯示，不影響資料儲存結構
Tab 把欄位分成不同頁籤顯示，跟 Accordion 一樣是純粹整理後台編輯體驗的工具，不影響資料實際儲存的結構。
跟 Accordion 的取捨在於呈現邏輯不同，Accordion 是垂直收合、可以同時攤開好幾組，Tab 則是同一時間只看得到一個頁籤的內容，切換到另一個頁籤前一個就會收起來。欄位分類邏輯清楚、彼此獨立（例如「基本資訊」、「SEO 設定」、「進階選項」）時，Tab 的切換體驗通常比 Accordion 更俐落。
Group 把相關欄位包成巢狀陣列
Group 把幾個相關欄位包成一個邏輯上的群組，前台程式讀取時要用巢狀陣列取值，不是像一般欄位那樣直接拿到單一值。
除了畫面上比 Accordion、Tab 更緊密地把相關欄位綁在一起，Group 還有一個實務上很重要的好處，能避免不同群組之間的欄位命名互相衝突。如果兩組不相干的欄位群組都想用「標題」當欄位名稱，包進各自的 Group 之後，前台取值時靠巢狀路徑就能明確分辨是哪一組的標題，不會互相覆蓋。
條件邏輯依前一個欄位的答案決定顯示或隱藏
條件邏輯（Conditional Logic）嚴格說起來不是一種獨立的欄位型別，而是每個欄位設定裡都內建的一個功能開關，免費版就能用。它的作用是讓某個欄位，或整組欄位，只在另一個欄位符合特定條件時才顯示出來，不符合條件就整組收起來，不佔編輯畫面的版面。
這解決的是欄位群組明明只有部分情境會用到、卻永遠攤在編輯畫面上的問題。舉一個常見情境，用一個 True/False 欄位問「這是不是活動類文章」，勾選之後才顯示「活動地點」、「報名連結」這組欄位，不勾就整組隱藏；編輯者面對的畫面永遠只有跟眼前這篇內容真正相關的欄位，不會被一堆用不到的輸入框干擾。
能拿來當判斷依據的欄位型別不是隨便挑，通常是本身就有明確選項值的類型，Select、Checkbox、True/False、Radio Button 這類最常拿來當條件依據，因為它們的值清楚、可預期，拿一個自由輸入的 Text Area 當判斷條件反而容易因為文字寫法不統一而誤判。設定方式很直覺，編輯目標欄位時打開 Conditional Logic 選項，指定要依據哪個欄位、要符合什麼條件，規則生效後，不符合的情境下那個欄位就不會出現在編輯畫面裡。
免費版把自訂文章類型與分類法整合進同一套介面
過去要在 WordPress 建立一個自訂文章類型，比如把「食譜」獨立出來，跟一般文章、頁面分開管理，WordPress 核心完全沒有內建的圖形介面，只能自己寫程式碼呼叫register_post_type()，自訂分類法也是同樣的狀況，得呼叫register_taxonomy()，兩個函式各自要設定的參數又多又雜，不熟悉程式碼的人幾乎沒辦法自己動手。
免費版 ACF 現在直接把這件事收進同一套後台介面裡，左側選單新增了「Post Types」與「Taxonomies」兩個項目，操作邏輯跟建立欄位群組完全一樣，點「Add New」，填單數與複數標籤等基本設定就能發佈，進階設定還細分成一般、標籤、可見度、URL、權限、REST API 幾大區塊，不必碰任何程式碼。這個功能是 ACF 6.1（2023 年）加入的，而且官方明確標示這不是 PRO 專屬功能，免費版所有使用者都能直接用。
對已經習慣用程式碼維護網站的開發者，ACF 也留了一條退路，做法是在「Tools」頁面裡勾選要匯出的項目，按下「Generate PHP」，就能拿到對應的程式碼片段，貼進主題的functions.php，之後移除 ACF 介面裡的設定、改用純程式碼維護。等於是先靠圖形介面快速建好雛形，確定沒問題之後再轉成程式碼版本長期維護，兩種做法可以無縫接軌。
傳統佈景主題顯示欄位資料，有函式、簡碼與頁面編輯器三條路
欄位建好、資料也填了，不代表它就會自動出現在網站前台，這是很多剛接觸 ACF 的人容易誤會的一點。這節講的是傳統佈景主題，也就是範本檔案用 PHP 寫成、像single.php這種會在伺服器端執行程式碼的主題，底下怎麼把欄位資料實際接到畫面上，共有三條路可以走。
第一條路是直接在範本檔案裡呼叫函式，the_field('欄位名')會直接把欄位值印在畫面上，適合單純顯示、不需要額外邏輯的情境；get_field('欄位名')則是先把值取回來，不直接輸出，方便加條件判斷或包進自訂的 HTML 結構再顯示。兩者的差別就在直接印出跟先拿到值再自己處理，實務上需要格式化或條件顯示的情境，幾乎都得用get_field()。
第二條路是簡碼，優點是完全不必碰主題檔案，直接寫進文章正文就能顯示欄位值；缺點是得逐篇文章手動加，沒辦法自動套用到所有內容，適合零星幾篇需要顯示、不值得改範本檔案的情境。第三條路則是交給頁面編輯器，多數主流頁面編輯器都提供類似的動態欄位串接選項，能在視覺化編輯畫面裡直接選取要顯示哪個 ACF 欄位，不必寫任何程式碼，也不用記函式名稱。
有一件事在讀取資料時要說明白，欄位所在的物件不同，儲存的資料表也不同，文章的欄位存在postmeta，使用者的欄位卻存在usermeta，兩者不是同一張表。這也是為什麼the_field()跟get_field()除了欄位名稱，通常還要指定第二個參數告訴函式這筆資料要去哪個物件底下找，少了這個指定，常見的結果就是欄位讀出來一片空白。
區塊主題不執行函式，免費版改用區塊綁定接資料
如果網站用的是區塊主題，也就是 Full Site Editing 那一套，範本檔案是single.html這種用 HTML 加區塊標記寫成、不是 PHP 的主題，前一節講的the_field()、get_field()完全不會執行。原因很直接，區塊主題的範本檔案本質上是靜態 HTML，WordPress 只負責把裡面的區塊標記解析成畫面，不會去執行寫在裡面的 PHP 程式碼；把the_field()硬塞進區塊主題的範本檔案，充其量只會被當成一段純文字顯示出來，不會真的抓到欄位值。
免費版的解法是 WordPress 6.5 加入的區塊綁定（Block Bindings API），讓段落、標題、按鈕、圖片這 4 種原生區塊可以直接連到 ACF 的欄位值，不必寫任何 PHP 範本。要用這個功能有兩個前提，WordPress 版本要在 6.5 以上，而且該欄位在設定裡的「呈現方式」要打開「允許在編輯器 UI 存取值」這個開關，沒開的欄位不會出現在可綁定的清單裡。
目前還沒有圖形化介面可以直接點選設定綁定，得切換到區塊編輯器的「程式碼編輯器」檢視，手動在區塊標記裡加上metadata.bindings屬性，指定要綁定哪一個欄位，這對不熟悉程式碼的編輯者來說，操作門檻確實比傳統的the_field()高一截。而且區塊綁定只能處理簡單的文字與圖片這類單一值欄位，遇到中繼器、相簿、群組或關聯這類結構複雜、一次帶多筆資料的欄位就處理不了，這部分留給後面會講到的 PRO 版 ACF Blocks。
另外有一件容易被忽略、卻涉及資安的設計，在區塊主題底下，ACF 的簡碼在文章內容區域之外預設是停用的，這是刻意的安全設計，避免有權限插入簡碼區塊的使用者，透過簡碼讀到不該讀到的欄位資料。真要在內容區域之外啟用簡碼，得另外加一道篩選器讓它回傳允許，但官方文件也明白提醒，開放之後任何能插入簡碼區塊的使用者都能讀到任何一個 ACF 欄位值，啟用前要清楚這層風險。
中繼器、彈性內容與選項頁，這些都是 ACF PRO 的專屬功能
前面每一節提到 PRO 專屬欄位時都先點名過一次。全部 35 種欄位型別裡，有 4 種是 PRO 版才有，Repeater、Flexible Content、Gallery、Clone，其餘 31 種免費版就能直接用，免費版的涵蓋範圍其實已經相當完整，PRO 版補的是幾種處理重複性資料與多變版面的進階欄位，加上選項頁跟完整版 ACF Blocks 這兩項機制。
Repeater 讓欄位可重複新增，筆數不用先定
Repeater（中繼器）讓你建立一組可以重複的子欄位，每重複一列，子欄位的結構都完全一樣。適合內容筆數不固定、但每一筆的欄位結構相同的情境，比如一篇文章要列出數量不定的常見問答或操作步驟，不知道會有 3 筆還是 8 筆，用 Repeater 就能讓編輯者自己決定要新增幾列。
免費版沒有這個型別，遇到不確定要重複幾次的資料結構，通常得靠拆成多個固定欄位硬湊，或改用前面講過的 Relationship 欄位去關聯到其他獨立的文章項目，兩種替代方案都不如 Repeater 直覺，這也是免費版使用者最常感受到限制的地方。
Flexible Content 每一列能換不同版面配置
Flexible Content（彈性內容）跟 Repeater 的差別在於，每一列可以自由選擇不同的版面配置（layout），每一種版面配置各自有自己的子欄位組合。適合頁面由多種不同區塊模組堆疊組成、順序跟種類都交給編輯者自己決定的情境，例如一個頁面要能自由插入文字區塊、圖文並排、影片嵌入，順序不固定，種類也不只一種。
這是一種更彈性的版本控制方式，Repeater 每一列的結構固定不變，Flexible Content 則讓每一列都可能長得不一樣，適合的場景是頁面編排需求本身就比較多變的網站，像是行銷活動頁或落地頁，常常需要臨時調整版面模組的順序跟種類。
Gallery 一次管理多張圖片，不必拆成多欄
Gallery（相簿）可以一次上傳、管理多張圖片並排序，適合作品集、產品多圖展示這類需要一組圖片、而不是單張圖片的欄位。免費版的 Image 欄位一次只能存一張圖，要放多張圖只能靠建立多個 Image 欄位硬湊，操作起來不如專門的相簿介面直覺。
跟前面 Content 分類講過的 Image 欄位比，Gallery 多了排序、批次管理這些專為多圖情境設計的介面，對需要展示大量圖片的網站，攝影作品集、產品型錄，是相對明顯的差距。
Clone 把設定好的欄位複製到別處使用
Clone（分身欄位）把已經存在的欄位、或整個欄位群組原樣複製到另一個位置重複使用，不必重新設定一次。常見情境是好幾個不同的欄位群組都需要同一組 SEO 設定欄位，用 Clone 就能一次設定、到處套用，不必在每個群組裡分別重建一遍。
免費版沒有這個機制，遇到同樣的欄位組合要在多個群組裡重複使用時，只能逐一手動建立，一旦要調整其中一個欄位的設定（比如改個預設值），就得回頭到每一個群組分別改一次，維護成本會隨著重複的群組數量往上疊加。
Options Page 建立獨立設定頁，不綁任何內容
Options Page（選項頁）在後台新增一個不綁在任何文章、頁面或使用者身上的獨立設定頁面，適合網站層級的全域設定，例如頁尾聯絡資訊、社群連結這類不屬於任何一篇文章的資料。前面「位置規則」那節提過，這是 PRO 版才有的位置類型，免費版沒有對應的建立入口。
沒有選項頁的情況下，免費版遇到網站層級的全域資料通常得繞道處理，比如借用某個固定頁面的自訂欄位當容器存放，或改成寫死在主題設定檔裡，兩種都不如選項頁乾淨，這是免費版在站級設定這塊比較明顯的功能落差。
完整版 ACF Blocks 能自寫 PHP 範本控制輸出
PRO 版可以用acf_register_block_type()註冊完整的自訂 Gutenberg 區塊，搭配 PHP 範本（render.php）控制輸出邏輯，能處理前面講過的中繼器、相簿這類複雜欄位型別，也能正確處理 Query Loop 迴圈裡的文章情境。免費版沒有這個函式可以用，只能靠前面講過的區塊綁定，功能簡單很多，也只能綁 4 種原生區塊。
差距最明顯的地方在能不能處理複雜資料結構，區塊綁定只能傳簡單的文字或圖片值給核心區塊，完整版 ACF Blocks 則能自己寫 PHP 範本，把 Repeater 裡一列一列的資料整個渲染出來，對需要客製化區塊、又牽涉到複雜欄位的網站，這是免費版目前補不上的缺口。
PRO 版讓自訂欄位直接對應 Schema.org 詞彙
這是 ACF PRO 6.8 新加的功能，可以直接把自訂欄位對應到 Schema.org 的詞彙，像是 Recipe、Product、Event 這類結構化資料類型，設定好對應關係之後，自動在前台輸出結構化資料標記，不必自己手刻 JSON-LD。官方明白標示這目前是實驗性功能，但支援的詞彙範圍已經涵蓋完整的 Schema.org 規範，共 867 種型別、1,509 個屬性。
結構化資料原本是需要額外外掛或自己手寫程式碼才能做到的事，把它直接整合進欄位設定介面，等於把填欄位、跟產生給搜尋引擎與 AI 系統讀的結構化標記這兩件事合而為一。免費版目前沒有這項功能，想要用 ACF 直接產生 Schema.org 標記，得升級到 PRO 6.8 以上的版本。
免費版也能讓 AI 工具直接讀寫欄位資料
把免費版跟 PRO 版的邊界畫清楚之後，還有一件事分不進那條界線，免費版最新加進來的功能，反而是把後台開放給外部 AI 工具直接操作。2026 年發布的 ACF 6.8 版加入對 WordPress Abilities API 的支援，而且明確強調這是免費版就有的功能，不是 PRO 專屬。Abilities API 是 WordPress 6.9 才加入的新機制，讓相容的外部 AI 工具能透過一套標準化的介面，理解並操作網站的內容模型。官方的說法很直接，ACF 6.8 導入 WordPress 6.9 全新的 Abilities API 支援，讓 AI 工具與自動化平台能透過標準化、安全的介面存取 ACF 的資料。
這個功能的定位不是請 AI 幫你寫文章，而是讓外部 AI 工具或自動化平台能看懂並操作網站的內容模型，欄位群組的結構、自訂文章類型、自訂分類法，都在可以被讀取跟操作的範圍內。舉一個具體的使用情境，可以直接請支援 MCP 協定的 AI 助理建立一個食譜文章類型、欄位包含食材、烹調時間、難度、步驟，對方就能透過這套介面直接生成對應的欄位群組，不必自己一項項手動建立。
開啟方式是在主題的functions.php加一行篩選器，add_filter( 'acf/settings/enable_acf_ai', '__return_true' );，啟用之後，後台會多出一個「ACF AI」設定分頁。權限設計採取逐項目手動授權的方式，已經存在的欄位群組、文章類型、分類法，預設全部不開放 AI 存取，得自己一項一項打開「Allow AI Access」開關才會生效，只有新建立的項目會預設開放。官方文件也直接點出這層設計的用意，AI 存取採逐項目選擇性開啟，確保敏感資料不會在無意間被曝露。
技術需求上，這套機制要 WordPress 6.9 以上、Advanced Custom Fields 6.8 以上，還得搭配一套支援 MCP 協定的用戶端或伺服器實作。所有透過這套介面執行的操作，一樣得遵守 WordPress 既有的使用者權限，執行者需要具備對應的能力設定，預設是manage_options；像刪除欄位群組這類破壞性操作，還需要額外的明確確認標註才會執行，不是接上 AI 工具就能無視原本的權限與安全機制。
走完這一輪會發現，免費版 Advanced Custom Fields 能覆蓋到的範圍其實遠比多數人想像的大，35 種欄位型別裡有 31 種免費就能用，連過去得靠寫程式碼才能做到的自訂文章類型、自訂分類法，現在也整合進同一套點選介面。真正被留在 PRO 版那一側的，是處理重複性資料與多變版面的中繼器與彈性內容、多圖管理的相簿、複製欄位設定的分身欄位，還有站級設定用的選項頁跟完整版的自訂區塊，這些欄位有沒有踩到，大致就能判斷免費版夠不夠撐起手上的網站。
唯一真正容易拖住整個上線進度的，反而不是欄位型別夠不夠用，而是主題本身用的架構，區塊主題底下，原本熟悉的the_field()、get_field()直接失效，得改用區塊綁定，而且目前還沒有圖形化設定介面，得手動改區塊標記。這一步常常被忽略，直到欄位建好、資料填了，前台卻什麼都沒顯示，才回頭發現主題早就換成了區塊主題架構。
從免費版最新加進來的 AI 存取功能也看得出，這套工具沒有停在幫後台加欄位這個原始定位上，而是持續往讓內容結構本身可以被外部系統理解、操作的方向走。對多數網站來說，免費版走到這裡，能做的事已經遠比第一次打開安裝畫面時想像的多。