Day 7｜別再把所有下拉都叫 Dropdown：從 Select 到 Multi-select 的選型指南

本文同步自 2026 iThome 鐵人賽原文 。完整系列可見 iThome 系列頁 。

安安～我是ChiYu～

昨天把通知設定拆成 Checkbox、Radio 與 Switch 後，邀請成員流程只剩兩個欄位：「所屬部門」和「協作者」。

部門要能搜尋，但只能從既有資料選一筆；協作者同樣要搜尋，卻可以留下多筆結果。AI 第一版很乾脆，兩個欄位都做成「可以搜尋、可以多選，也可以自己輸入」的 Dropdown。

先看所屬部門：

圖 1：輸入框與候選清單都有出現，資料邊界、選取結果和非理想狀態則全部缺席。

原始實驗在 2026 年 7 月 23 日執行，使用 Codex Desktop、GPT-5、相同的六筆虛構部門資料，以及 Astro／TypeScript 環境。整理文章時，我又在 7 月 27 日用原始 Prompt 重跑這張基準，沒有追加任何說明：

幫我做一個好用、漂亮、可以搜尋的下拉選單。

一顆元件包辦所有能力，聽起來很省事。實際上，每多塞一種能力，就多一條還沒說清楚的資料規則：輸入的文字算搜尋條件，還是新資料？按下 Enter 是選取，還是建立？多選後的值又放在哪裡？

按下 Enter，是選取「研究組」，還是建立一個新部門？

我在第一版輸入「研究」，畫面確實列出「研究組」。

接著才是麻煩。按下 Enter 後，它應該選取 API 裡既有的「研究組」，還是替系統建立一個叫「研究」的新部門？原始需求沒說，畫面也沒回答。

載入中、無結果、失敗與停用同樣不存在。只看靜態截圖，很容易把「有輸入框、有清單」當成完成版；真的要把值送進系統時，資料契約才開始追著我們問答案。

這次我的選擇很明確：所屬部門使用只能選既有值的可編輯 Combobox。管理員可以輸入關鍵字，但最後只能提交 API 裡既有的一個部門。這條規則排除了自由文字，也排除了不方便搜尋大量資料的普通 Select。

Combobox 並不是天生只能選既有值。W3C 的模式同時涵蓋可自由輸入，以及只能從允許值中選擇的做法；Autocomplete 則描述候選值如何隨輸入出現。這篇把幾個名稱拆開，是為了讓 Prompt 比較好說，不代表所有設計系統都會用完全相同的方式切界線。

先寫三條資料契約，再替「下拉選單」選名字

遇到 Dropdown 需求時，我會先問三件事：

1. 輸入是在查資料，還是建立資料？
2. 最後的值是否必須來自系統？
3. 一次要留下幾筆？

答案寫出來，Select、Listbox、Combobox、Autocomplete 與 Multi-select 才有辦法分工。

「可搜尋」只回答怎麼找到資料；「可多選」決定要保留幾筆；「可自建」則會直接改變資料來源。把三句混成「做一個厲害的 Dropdown」，AI 只能把功能當自助餐往裡面裝。

我把這組判斷整理在 Select、Combobox、Autocomplete 完整比較頁 ：

圖 2：確認能否輸入、是否只能選既有資料、能不能建立新值，以及一次選幾筆後，五種選項已經不再是同一顆 Dropdown。

如果還在兩三個候選之間猶豫，再沿著這張圖走一次：

圖 3：是否需要輸入、值是否受限，以及單選或多選，是排除錯誤元件的三個主要分岔點。

單選既有值：選項少用 Select，資料多再交給 Combobox

Select 讓人直接挑一個固定答案

Select｜選擇器 適合選項少、內容一眼能掃完，而且只需要一筆既有值的情境，例如所屬校區或表單語言。

圖 4：選項數量少時，Select 讓使用者直接挑一個答案，不必先輸入關鍵字。

如果選項有上百筆，硬塞進 Select 只會讓人一直滑。這時增加搜尋也不是替 Select 裝一個放大鏡就好，焦點、候選清單與鍵盤行為都要一起處理，Combobox 會比較合適。

Combobox 可以搜尋，但最後仍只收既有部門

Combobox｜組合式選擇框 可以做成 select-only，也可以允許輸入文字。LumenDesk 的所屬部門採用可搜尋、單選，而且只接受既有部門的版本。

我在 Demo 輸入「研究」，按方向鍵往下，再按 Enter，最後選到既有的「研究組」。

圖 5：輸入「研究」後顯示既有候選項目；方向鍵移動焦點，Enter 才完成選取。

接著我改輸入不存在的名稱。畫面進入無結果，沒有默默把自由文字升格成新部門；按 Reset 後又能回到初始狀態。

圖 6：輸入、候選清單、目前值與鍵盤操作要一起設計，少一塊都會留下猜測。

這三步就是我對這次 Combobox 的基本驗收：輸入只負責縮小既有資料、不碰滑鼠也能選取、無結果與重設都有明確回應。載入失敗和停用也不能只存在 Prompt 裡。

選項要常駐、提供建議或保留多筆，責任又不一樣

Listbox 把選項留在畫面上

Listbox｜選項清單 適合權限清單、篩選側欄，或需要直接瀏覽的選取清單。

圖 7：候選項目持續可見，使用者能同時看到焦點位置與目前選取值。

它的優勢正是不用每次展開才看得到選項。反過來，資料多到必須輸入關鍵字才能找到時，單靠 Listbox 就不夠。

Autocomplete 提供建議，不會替產品決定能否自由輸入

Autocomplete｜自動完成 會在輸入途中提供候選建議，常見於收件者、地點或文章標籤。它比較像輸入與候選清單的行為模式，不一定是和 Combobox 完全分離的另一顆元件。

圖 8：Autocomplete 幫使用者縮小輸入範圍，但候選清單以外的文字能不能留下，仍要由需求決定。

建議從哪裡來？沒選建議時能不能送出？這兩題若沒有答案，它可能接近受限資料的 Combobox，也可能只是一般 Text Field 的輸入輔助。

Multi-select 要讓已選內容留在畫面上

Multi-select｜多選選擇器 適合指派多個標籤或邀請多位協作者。它可以是持續展開的多選 Listbox，也可以是搜尋後把已選值顯示成 Chip 的 Combobox；LumenDesk 的協作者欄位採用後者。

圖 9：已選協作者留在欄位附近，每一筆都有清楚移除方式，也能看見選取上限。

只在展開清單裡打勾不夠。清單收起來後，使用者仍要知道自己選了誰、如何移除其中一筆，以及還能再選幾位。若最後只需要一個部門，就不要讓單選欄位背著整套多選狀態到處跑。

這次只改「所屬部門」，Prompt 也只寫一個 Combobox

把五種名稱都塞進同一份 Prompt，看起來很完整，卻容易把今天真正要修的欄位淹沒。這次我只處理所屬部門：

建立一個單選 Combobox，讓工作區管理員從既有部門中搜尋並選取一項。

資料由 API 載入，不可自行新增部門。輸入關鍵字時篩選選項；
方向鍵移動候選項、Enter 選取、Escape 關閉。

提供 Default、Selected、Loading、Empty、Error、Disabled 與 Reset。
360px 下仍要看得到 Label、選取值與錯誤訊息。
使用可見 Label、combobox／listbox 語意、清楚 Focus 與狀態訊息。

驗收：不用滑鼠也能搜尋並選到既有部門；載入失敗時能理解問題並重試。

第二版輸入「研究」後按方向鍵與 Enter，值會成為「研究組」並收合清單。輸入不存在的內容則進入無結果，不會偷偷建立新部門；Reset 能回到初始狀態，切到 Disabled 時也不會留下仍可操作的清單。

這次仍有三件事不能蓋章：

• Demo 使用靜態資料，沒有真實 API 延遲與權限。
• 尚未使用螢幕閱讀器實聽。
• 200% 縮放還沒列入阻擋條件。

所以我可以說鍵盤流程與 360px 已通過，不能把所有使用方式一起包成「驗證完成」。

邀請流程走完後，下一張表單開始和數字過不去

回到這幾天一直處理的邀請流程：使用者先用 Link 查看權限說明，接著填帳號與備註、選擇通知方式，再用 Combobox 從既有部門選到「研究組」。若要加入多位協作者，欄位改用 Multi-select，已選的人會留在畫面上。最後按下送出；失敗時資料保留，成功後才關閉 Dialog。

這是 LumenDesk 第一條走通的完整任務，後台當然還沒做完。

新團隊接著要建立內部活動。預算是 48,000 元、配送距離要微調、餐點數量要增減，活動結束後還得留下滿意度。全部都是數字，AI 很自然地送它們一人一條 Slider。

圖 10：五個數字都有顯示，卻只能靠拖曳修改。精確預算、少量餐點與主觀評價暫時被當成同一份工作。

明天要處理的不是 Slider 的配色，而是這五個數字究竟要多精確，又該用什麼方式修改。

參考資料與查閱日期

• W3C WAI：Combobox Pattern
• W3C WAI：Listbox Pattern
• MDN：<select>

資料查閱：2026-08-07。