WooCommerce 縣市下拉：RY WC City Select 教學

WooCommerce 核心已有台灣縣市下拉資料，鄉鎮市區對應的 city 欄位則通常是文字輸入。免費的 RY City Select for WooCommerce（舊名 RY WC City Select）可依所選縣市提供鄉鎮市區清單，減少部分手動輸入。本文說明欄位對應、安裝與金物流驗收；它不會驗證門牌是否存在，也不能保證不再填錯地址。

W3Techs 的統計可用來了解 WooCommerce 普及程度，實際選擇地址工具仍要看商店需求。台灣結帳資料通常以 country 放國家、state 放縣市、city 放鄉鎮市區，address 欄位放街道門牌。超商門市代碼與宅配地址是不同資料；下拉選單不是所有物流與運費自動化的必要前提。

一個打錯的縣市，到底會吃掉你多少成本

假設客人選錯縣市，卻填入另一地區的街道門牌，商店可能需要聯絡確認、改單或重新寄件。這是說明資料不一致的示例；是否退件與產生多少費用，仍要看物流查核與實際處理，不能只憑欄位型態判斷。

大型家具等商品的退件成本可能較高，值得把地址錯誤單獨記錄。連動清單可減少縣市與鄉鎮市區不一致的輸入，但選錯選項、舊地址與門牌錯誤仍會發生。改善幅度應由商店的錯誤紀錄與測試結果確認。

下拉選單用固定選項換取較一致的資料，也可能增加查找與操作時間。選項完整、預填正確、能用鍵盤和手機操作，才有機會改善填寫體驗；它不會自動讓所有地址正確。

三種做出縣市下拉選單的方法，我為什麼挑 RY WC City Select

要把那個欄位換成下拉選單，實務上有三條路。我先把它們擺在一起比，你會很清楚為什麼我長期偏好第三條。

比較時要看清單是否完整、縣市與鄉鎮市區是否相依，以及傳統與區塊結帳的支援程度。不同欄位編輯器版本有不同能力，不能一概說都不支援連動。RY City Select 的核心用途是提供相依城市選單，適合先在測試站驗證。

這支外掛與 RY WooCommerce Tools 出自同一開發者，可能有助維持台灣地址與物流格式的一致性，但實際相容性仍要依版本、WooCommerce 設定與金物流外掛測試。若準備串接綠界，可一併核對兩支外掛的支援範圍與更新紀錄；整體選擇則可參考電商外掛評測。

WooCommerce 的地址模型跟台灣差在哪：先搞懂為什麼預設會卡住

WooCommerce 地址包含國家、州／省／縣市、城市、街道門牌與郵遞區號等欄位，標籤及必填條件可依國家調整。理解資料對應，比把它簡化為固定三層地址更有助排錯。

在台灣常見的欄位對應如下。它不要求改變核心資料結構，主要是決定哪些欄位適合用清單、哪些需要自由輸入：

看出問題了嗎？WooCommerce 其實有為台灣準備 state 清單，所以 billing_state 那一層預設就有 22 個縣市的下拉。但 billing_city 那一層，它沒有為台灣準備對應的鄉鎮市區清單，於是就退化成一個空白的文字輸入框。這就是為什麼很多站長以為「我有裝 WooCommerce、也有選台灣，地址應該沒問題」，結果一打開結帳頁，縣市是下拉、區卻是輸入框，一半結構化、一半放牛吃草。

RY WC City Select 補的，就是 billing_city 這一層的結構化。它做兩件事：第一，把 city 欄位從文字框換成下拉；第二，讓這個下拉根據你選的 state（縣市）連動，只顯示那個縣市底下的區。換句話說，你不是在「新增一個功能」，你是在「補完 WooCommerce 為台灣沒有做完的那一哩」。這個認知很重要，因為它解釋了為什麼這支外掛要跟 billing_state 緊密搭配，也解釋了為什麼後面會強調預設國家要設成台灣：連動需要先有正確的 country 與 state；跨國商店則應保留實際需要的國家，不必把所有顧客預設為台灣。

這個結構性的理解，也會幫助你之後 debug。當某一層的連動壞掉，你會知道是 state → city 這條鏈斷在哪裡，不會把整個結帳表單從頭懷疑一遍。

訪客結帳與會員地址：下拉清單在兩種情境下的差別

結帳頁不是只有一種使用情境，它至少分成「訪客結帳」與「會員登入結帳」兩種，下拉選單在這兩種情境下的行為不一樣，你要分開測試。

訪客結帳應測試全新的購物流程，也要測試返回結帳的情境。未登入不代表每次都會建立新 session；瀏覽器自動填寫、既有購物車與預設顧客位置都可能預填地址。請確認各種起始值下，鄉鎮市區能連動，運費也會依地址更新。

會員登入結帳就複雜多了。WooCommerce 會把會員上一次用的地址帶進來預填，下拉應該要自動預選那個縣市與區。問題是，如果你的站以前沒有結構化地址，會員資料表裡存的是自由輸入時代的舊值—可能是「台北市」，可能是「taipei」，可能是某個連你自己都看不懂的拼法。這些舊值會在會員結帳時被帶出來，跟新的下拉邏輯對不上，輕則下拉預選不到正確的值、客人要手動重選，重則連動直接卡住、區欄位空白。

這裡有一個很容易被低估的坑：你裝好下拉、測完訪客流程、覺得一切正常，但你的老會員登入結帳時，帶入的還是髒的舊地址。所以測試的時候，一定要找一個「之前下過單的老會員帳號」實際走一次結帳，看看地址帶入的時候下拉有沒有正常預選。如果你也開放會員在「我的帳號」頁面編輯地址（多數 會員系統都會），那個地址編輯表單也要測，確認下拉在那裡的行為跟結帳頁一致。

舊髒值要不要清？我的建議是分兩步走。第一步，接受它：先確認新訂單與會員地址儲存的實際行為，讓顧客校正無法對應的值；不要假設每次下單都會覆蓋舊會員地址。第二步，如果你的站對地址乾淨度要求很高（例如要做精準的區域行銷、或要匯出給 ERP），那就需要寫一個一次性的資料清洗腳本，把會員資料表裡的地址標準化。這一步是進階操作，建議交給熟悉 WooCommerce 資料結構的開發者處理，不要自己硬改資料庫，改壞了會員地址是很難救回來的。

這整段的潛台詞是：下拉選單不是裝完就天下太平，它跟你站上既有的會員資料之間，有一個過渡期要處理。心裡有這個譜，裝完之後才不會被老會員的怪地址嚇到。

安裝前要先確認的三件事

很多人裝外掛的習慣是「搜尋、安裝、啟用、出問題再說」。我不建議你在結帳頁這樣玩，因為結帳頁壞掉的代價是直接掉單，而且你可能不會馬上發現。動手之前，花三分鐘把下面三件事確認掉。

1. 主題的結帳頁範本有沒有被改過

有些 WooCommerce 佈景主題會覆寫傳統結帳範本，區塊佈景則可能使用 Checkout block。先在 WooCommerce 系統狀態核對範本覆寫，再辨識結帳頁的類型；不要只找到一份 form-checkout.php 就認定它一定控制目前結帳畫面。安裝後需測試實際使用的範本與外掛組合。

2. 有沒有已經在改結帳欄位的外掛

RY WC City Select 的核心功能是把城市／鄉鎮市區欄位改成依國家與州／縣市選擇的下拉選單，不能因此推定它接管所有地址欄位。若同時使用 Checkout Field Editor 或其他 結帳表單客製化 外掛，先核對是否都在改寫 billing_city、shipping_city 的類型與選項，再指定由哪一套設定負責。其他欄位的新增、排序與驗證仍依實際外掛功能處理，並測試縣市切換、舊地址預填與物流資料。

3. 備份，包含資料庫

這不是廢話。外掛啟用時會寫入選項資料表，停用時不一定完全清乾淨。裝之前用 UpdraftPlus 或你慣用的備份工具跑一次完整備份，包含資料庫。萬一設定跑掉，你有一個確定能還原的點。這個動作花你兩分鐘，但它是你能放心實驗的前提。

一步步安裝與啟用：讓城市清單出現在結帳頁

前置檢查做完，安裝本身很直覺。如果你完全沒裝過外掛，WordPress 外掛安裝的三種方法我這裡不重複，只講這支外掛實際會遇到的狀況。

1. 核對環境並安裝：從 WordPress.org 搜尋「RY City Select for WooCommerce」，作者為 Richer Yang。查核時最低需求為 PHP 8.2、WordPress 6.8、WooCommerce 10.0；以安裝當時外掛頁為準。
2. 確認地址資料與結帳類型：外掛依 country、state 載入 city 清單，不要預期一定有獨立設定分頁。先在測試站檢查實際採用的傳統或區塊結帳。
3. 設定銷售與運送地區：在 WooCommerce 一般設定選擇服務國家；預設顧客位置可用商店所在地、未指定或地理定位，並不是另一個可直接選台灣的欄位。
4. 測試訪客與會員：選台灣及不同縣市，檢查鄉鎮市區、郵遞區號、帳單和運送地址；會員預填地址也要另外驗證。

到這一步，外掛本身已經跑起來了。但「跑起來」不等於「正確」，接下來的中文化與地區清單才是重點。

中文縣市與鄉鎮市區清單的正確設定

台灣通常以 billing_state 保存縣市、billing_city 保存鄉鎮市區，街道門牌另填 address 欄位。RY City Select 讓 city 選項依 state 改變；請核對顯示標籤、實際儲存值與物流外掛送出的完整地址，三者不一定是同一字串。

台灣的 22 個縣市要齊全

核對商店服務範圍內的縣市與鄉鎮市區是否完整，離島也要測試。縣市清單、運送區域及物流可配送範圍各有作用；不提供某地配送時，應設定運送限制，不能只刪除下拉選項。

注意「台」與「臺」的寫法

「台」與「臺」在字串比較時不同，但物流系統是否接受、轉換或拒絕，取決於實際 API 與外掛處理。串接 綠界 ECPay時，應檢查送出的完整地址、郵遞區號和回傳結果，不要只因兩種字形不同就認定一定會建單失敗。

鄉鎮市區的連動要驗證

選了新北市之後，下一欄應該出現新北市底下的 29 個區，從板橋、三重一路到萬里、烏來。你要每個都點嗎？不用，但你至少要抽幾個縣市、各選一兩個區，確認連動真的生效；萬一整包鄉鎮全部塞在同一層給你選，就代表連動根本沒接上。連動失敗時，檢查國家與縣市值、清單內容、腳本錯誤，以及結帳區塊、範本或其他外掛的相容性。

用 Loco Translate 把顯示文字中文化

外掛的欄位標籤、placeholder、錯誤訊息可能還是英文。與其在主題的 functions.php 裡硬改文字字串，不如用 Loco Translate 建立這支外掛的翻譯集，把「City」「District」「Select a city」這類字串一次中文化。請將自訂翻譯存到 Loco 的 Custom 位置，並保留備份；外掛更新後若原文字串改變，仍需同步與補譯。

串接綠界與超商物流時要驗證的六個欄位

如果你站上同時跑綠界金物流，整體的金流物流設定又是另一條主線，這裡只聚焦一件事：RY WC City Select 設好之後，跟物流外掛之間還有一道驗證要做。綠界的物流 API 對地址格式有明確要求，以下六個欄位是我會逐項檢查的清單。

宅配和超商取貨應分開驗收：宅配需要完整收件地址與郵遞區號，超商訂單則需要選店流程回傳的門市代碼。表單欄位和 API 參數不一定一對一；以實際送出的資料與服務商回傳碼判定，不能把「台／臺」寫法當成通用拒絕條件。

若 運費規則依縣市或郵遞區號計價，變更地址欄位後要測試本島、離島與不服務地區。核心縣市選項可能儲存代碼，運費也可能按郵遞區號判斷；不能直接推論改用下拉就會提高規則命中率。

行動版下拉選單的體驗調校

請從商店自己的裝置與結帳數據確認行動版需求。全球網站流量統計只能提供背景，不能代表你的結帳訪客比例或證明下拉選單會提升成交率。實際測試手機上的選項查找、預填和錯誤提示。

下拉選單要測桌機與手機

RY City Select 的用途是讓 city 欄位依所選國家與州／縣市顯示城市清單；實際下拉是否可搜尋、由哪個腳本呈現，取決於結帳型態、主題與外掛版本，不能預設桌機一定有可搜尋框。請在桌機與實機手機分別測試選項開啟、查找、預填與送出；若位置錯亂或點不開，再檢查腳本錯誤與樣式衝突。

下拉框的觸控大小

原生 select 在手機上會叫出系統的選擇器，觸控體驗通常沒問題。但 selectWOO 這種自訂下拉，如果主題的 CSS 沒處理好，選項之間的間距會太窄，手指點下去容易誤觸隔壁的區。這時候要回到 CSS box model 的基本功，調 padding 與 line-height，可把至少 44 × 44 CSS px 作為較寬裕的觸控目標；WCAG 2.2 AA 的 Target Size (Minimum) 原則為 24 × 24 CSS px，並有間距等例外，不能只看高度判定合規。如果你對 CSS 還不熟，CSS 入門的觀念在這裡會直接派上用場。

結帳頁的整體載入速度

web.dev 的速度說明可作為效能評估背景，但實際結帳要包含地址、運費與付款互動的測試。依 網站快取指南排除購物車與結帳的全頁快取，並核對資源載入；延遲 JavaScript 可能破壞連動或選店，不能直接視為安全。PageSpeed Insights 的單次分數也不能取代完整結帳驗收。

如果你用的是 Elementor 這類頁面編輯器來做結帳頁的視覺，RWD 電商設計的考量也要一併照顧到，下拉框在不同螢幕寬度下的寬度、斷行行為，都會影響客人的填寫節奏。

五個最常踩到的錯誤與修法

以下是遇到問題時的檢查方向，不能只憑症狀確定原因；建議在測試站逐項驗證：

這張表的邏輯是：症狀是表象，原因通常出在「欄位控制權」「語言與清單」「前端腳本」「字串一致性」這四個層面。下次遇到沒列在上面的狀況，順著這四個層面往下想，多半能找到方向。

設定完成後，怎麼知道真的有效

改完一個東西卻不量測，等於沒改。下拉選單裝好之後，我會盯三個指標，給你做參考。

第一個是結帳完成率。在改之前先記下你目前的結帳轉換率（加入購物車到完成訂單的比例），改完之後兩到四週再比一次。這個數字會受到太多因素干擾（季節、促銷、流量來源），所以不要期待它直線上升，觀察期間應有足夠樣本，並控制流量、促銷等變化。若完成率下降，先檢查錯誤紀錄與各裝置流程，不要直接判定是下拉造成。

第二個是退件率與客服工單。這是我最在意的指標。地址打錯造成的退件、客人主動反映「我地址填錯了能不能改」的訊息數量，可作為改善前後的比較指標，但不保證下降。這個指標的好處是它直接對應成本，每一筆減少的退件都是實實在在省下來的運費與客服時間。如果你有用 訂單 LINE 通知，客服那邊收到的「地址問題」訊息頻率會是一個很直覺的觀察點。

第三個是填寫時間與錯誤次數。若要量測從進入結帳到送出訂單的時間，需事先定義事件、排除重試與離開再返回等情境；GA4 不會自動知道每個地址欄位的填寫時間。下拉是否更快，也要用實際資料與使用測試判斷。

把這些指標和實際錯誤紀錄一起看。未改善可能是樣本不足、選單本身有問題，或其他結帳因素造成；不能只憑趨勢就排除下拉選單的影響。

三個我會勸你不要踩的設定地雷

看完該怎麼做，反向也要講一下不要做什麼。這三個是實務上最常見、後果也最麻煩的錯誤設定，一開始就避開，比之後補救省事太多。

第一個，不要在結帳頁同時跑兩支會搶 billing_city 的外掛。我前面提過欄位控制權的問題，這裡再強調一次，因為重疊的欄位控制會增加排錯難度。常見的組合是：你原本用 Checkout Field Editor 把 city 改成了 select，後來聽說 RY WC City Select 更好用，就直接裝上去、沒停用原來的設定。兩支外掛都在 hook 同一個欄位，結果是下拉時而出現、時而消失，或選項變成兩份清單混在一起。這種間歇性問題最折磨人，因為它有時候正常、有時候不正常，你很難穩定重現。原則很簡單：同一個欄位，只讓一支外掛負責。

第二個，核對送往物流端的資料轉換。WooCommerce 儲存值、畫面標籤與 API 參數可能不同。先確認外掛如何組合地址，再以宅配與超商測試單驗證；不要自行大改核心縣市代碼來迎合單一標籤寫法。

第三個，不要在沒備份的狀況下，直接對會員地址資料表做大量更新。我在前面提過舊髒值的清洗，這裡要補一個警告：地址資料表是會員信任的基礎，客人存的地址被改錯，他下次結帳會帶入錯誤地址，直接出貨到錯的地方。任何對會員地址的批次更新，都要先在測試環境跑、先備份、先小量驗證。如果你沒有測試環境，至少先匯出一份完整的會員地址備份，再動手。這不是膽小，這是對客人資料的基本尊重。

這三個地雷的共同點是：它們都是「省了當下的麻煩，卻把更大的麻煩延後」。結帳頁是收銀台，收銀台不適合走捷徑。

把這件事放進你更大的結帳優化藍圖

縣市下拉選單不是一個孤立的設定，它是結帳流程優化裡的一塊拼圖。把它裝好之後，你可以順著這條線往兩個方向延伸。

往「欄位精簡」的方向：把結帳表單上不必要的欄位砍掉、把可以合併的欄位合併，讓客人面對的填寫項目越少越好。這部分可以搭配結帳表單客製化的整體策略，把欄位的順序、必填與否、預設值都重新想一遍。一個乾淨的結帳表單，效果不亞於任何轉換率優化工具。

要依地區規劃 動態定價、離島運費或 優惠券限制，先確認工具支援的條件與實際讀取欄位。這些功能不全是 WooCommerce 核心能力，也不都依賴 city 下拉；地址工具能協助提供一致資料，不能代替各項規則的設定。

如果你正在從零架一個 WooCommerce 站，這件事最好在建站階段就做好，等訂單量大了再回頭改會事倍功半。一開始就把地址結構化，仍要隨服務地區、物流與版本變更維護。也因此，我們在 WooCommerce 完整教學裡，會把結帳欄位的結構化列為必做的基礎設定之一。

清單不是設一次就永遠不用管：長期維護的觀念

行政區資料、外掛清單與物流規格都可能更新。更新後應確認舊會員地址能否預填、欄位值是否仍正確轉換，以及運費與出貨流程是否正常；不必假設每次顯示文字改變都會導致 API 失敗。

所以我把「核對縣市清單」當成一年一度的例行工作，裝完就忘記是最危險的做法。每年挑一個固定的時間（例如會計年度結束、或站慶前後），照著以下幾件事走一遍：

• 核對 22 個縣市：照著內政部的最新行政區清單，把下拉裡的縣市逐一勾一遍，確認沒有缺漏、也沒有被改成奇怪的寫法。
• 抽查連動：每個直轄市各選一兩個區，確認鄉鎮市區的連動還正常，沒有因為外掛或主題更新而失效。
• 對一次物流 API 的字串：核對實際傳送的完整地址、郵遞區號或門市代碼，並依該 API 的回傳結果驗證。
• 檢查翻譯：如果你用 Loco Translate 改過顯示文字，更新外掛後要回去看翻譯是不是還對得上新的字串。

這個年度檢查花你大概半個小時，但它能避免一種最冤枉的事：外掛默默更新、字串默默改了、訂單默默卡在物流、你兩個月後才發現。地址是地基，地基偶爾要回頭看一眼有沒有裂縫，這不是過度謹慎，這是基本的營運紀律。

外掛本身的更新也要納入管理。RY WC City Select 跟其他 WordPress 外掛一樣會發新版本，更新前先備份、更新後跑一次完整的結帳測試（訪客加會員兩種情境都走一遍）。如果你有設定 快取外掛或 WP Rocket 這類工具，更新後記得清一次快取，因為舊的 JS 有時候會被快取住，讓你以為連動壞了，其實只是瀏覽器抓到舊檔。

收尾：地址欄位是轉換率的最後一哩

結帳頁是一個網站的收銀台，而地址欄位是收銀台裡最不起眼、卻最容易漏單的一格。把它從自由輸入換成結構化的下拉選單，投入的時間不多，但它影響的是退件、客服、物流串接、運費規則這一整條鏈。這不是一個會讓你流量暴增的設定，實際效果仍要看選單設計、地址資料與物流流程是否改善。

先以訪客與既有會員各走一次結帳，確認縣市和鄉鎮市區各自的欄位用途。若鄉鎮市區仍是文字輸入，評估是否需要相依選單，再以足夠的訂單與錯誤紀錄比較調整前後表現。

我們在 Whoops 處理過不少 WooCommerce 站的結帳優化，從欄位結構、金物流串接到轉換率提升，如果你卡在某個環節不知道怎麼往下走，這是我們能幫上忙的地方。把這篇當成你自己動手的第一份指南，需要更多人一起看著全局來調的時候，再把我們叫進來。卡關了，Whoops 隨時能陪你把結帳這一哩走順。