RWD尺寸怎麼定？斷點設計原則與常見裝置寬度對照表

作者｜瞻新資訊　陳俊鳴顧問（資深SEO顧問・搜尋流量與銷售漏斗規劃）

「RWD尺寸」這個關鍵字，多半是已經確定要做響應式網站的人在搜尋——你不是在問「要不要做RWD」，而是想知道一個更具體的問題：斷點到底該設在幾px，手機、平板、桌機的合理寬度區間是多少，業界慣用的數字又是什麼。這篇文章把這些數字攤開，也講清楚一件更重要的事：斷點不是抄一組數字就能用一輩子，它該由你的網站內容決定，不是由某支手機的型號決定。

「斷點」是什麼？跟RWD尺寸的關係先弄清楚

斷點（breakpoint）指的是網頁版面切換排列方式的那個螢幕寬度。手機螢幕窄，內容排成單欄；螢幕變寬到某個程度，版面改排成兩欄、三欄，甚至選單從漢堡按鈕展開成橫向列表——那個「版面開始改變」的寬度，就是斷點。RWD尺寸講的其實就是這些斷點該設在哪裡，以及斷點兩側的螢幕寬度分別要怎麼設計。

技術上，斷點是用CSS的media query寫出來的條件式：螢幕寬度小於某個值套用一組樣式，大於某個值套用另一組樣式。這一步留到後面的語法段落再拆解，這裡先記住一句話：斷點不是裝飾用的技術名詞，它是「內容在什麼寬度下會讀不下去、排不下去」的那個轉折點。

手機、平板、桌機的合理寬度區間：一張表先抓住大概位置

在深入細節之前，先給一個可以直接參考的大方向。多數網頁設計公司在實務上，會把螢幕寬度切成三到四個區間分別設計版面：

裝置類型	常見寬度區間	設計重點
手機（直式）	320–767px	單欄排列，字級與按鈕要夠大好點擊
平板（直式／橫式）	768–1023px	過渡區間，容易被忽略，常卡在手機版跟桌機版中間
桌機（一般螢幕）	1024–1439px	多欄排列，選單完整展開
大尺寸桌機／大螢幕	1440px以上	版面要控制最大寬度，避免內容被拉得過寬難閱讀

這四個區間不是四種完全獨立的設計，而是同一套內容依寬度逐漸展開的過程，桌機版看到的資訊量比較多，不代表手機版要把東西刪掉，而是重新安排出現的順序。這張表的分界也不是憑空訂的，768px這個常見分界點，歷史上是沿用iPad直式螢幕的寬度（1024×768px），後來被許多前端框架與設計工具沿用成慣例，不是Apple或任何機構訂出的強制標準。這也是為什麼下一段要特別講：不同框架的預設斷點，其實彼此都不一樣。

業界怎麼抓斷點？Bootstrap跟Tailwind的預設值不一樣

如果你問工程師「斷點應該設多少」，得到的答案通常會參考某個前端框架的預設值——最常見的兩套是Bootstrap與Tailwind CSS。把兩者官方文件列出的預設斷點放在一起看，可以清楚看到一件事：

尺寸級別	Bootstrap	Tailwind CSS
極小（xs）	0px	（無獨立級距）
小型（sm）	576px	640px
中型（md）	768px	768px
大型（lg）	992px	1024px
特大（xl）	1200px	1280px
超大（xxl／2xl）	1400px	1536px

兩套框架唯一完全一致的只有「md」這一級的768px——也就是前面提到的平板分界慣例；其他級距各有各的取捨，Bootstrap官方文件甚至寫明每個斷點的選定是為了讓容器寬度能剛好被12整除、方便12欄格線系統運算，跟Tailwind的取捨邏輯完全是不同的出發點。這說明一件事：斷點沒有一個放諸四海皆準的正確答案，576px跟640px都能是合理的手機分界，差異在於設計者當初依照什麼內容密度、什麼欄位邏輯做的判斷。兩套框架都是全球開發者長期實測過的成果，拿來當起點很合理，但不代表其中一套就是「唯一正確」的標準。找廠商討論規格時，與其糾結「你們用的斷點是不是業界標準」，不如直接問一句「這些數字是根據什麼內容決定的」——這個問題比較容易問出對方真的有沒有規劃過。如果你連要不要走RWD都還沒決定，這牽涉的是更前面一層的技術路線選擇，可以先參考RWD跟AWD自適應設計的差異比較。

台灣手機使用者實際用什麼尺寸？

除了框架預設值，另一個該參考的是真實使用者的裝置分布。根據Statcounter統計，台灣手機螢幕解析度排名前五名（2026年7月資料）如下：

排名	解析度	市佔率
1	414×896	29.77%
2	390×844	11.36%
3	384×832	3.86%
4	360×800	3.77%
5	393×852	2.69%

把這五個數字攤開會發現，台灣手機使用者的螢幕寬度高度集中在360px到414px這個區間，前五名加起來超過五成市佔。這代表如果你的手機版斷點設在767px以下、實際版面又是以360–414px為主要測試寬度，多數使用者看到的畫面會是你真正設計過、確認過的樣子，而不是憑感覺猜出來的。

但這裡也要提醒一件容易被誤解的事：看到「主要集中在360–414px」，不代表可以只針對這個寬度死板地設計，因為市佔前五名加起來也才五成出頭，剩下近五成的使用者用的是其他尺寸。這正是下一段要講的重點——尺寸資料是拿來當「合理範圍」的參考，不是拿來鎖死成單一目標寬度。

斷點該讓內容決定，不是讓裝置品牌決定

這是整篇文章最想講清楚的一件事，也是不少網頁設計提案容易被忽略的地方：斷點應該由內容版面實際出現擠壓、換行或跑版的寬度決定，而不是套用某支特定手機型號的螢幕寬度。

打個比方，開手排車的老司機不會固定在時速三十、五十、七十公里換檔，他聽引擎的聲音、看轉速表，引擎開始「卡」的那個轉速，才是真正該換檔的時機。斷點的邏輯也一樣：不是抄別人時速表上的固定數字，而是看自己網站的版面在哪個寬度開始「卡」——文字擠成一團、按鈕疊在一起、表格被壓得看不清楚，那個寬度才是你真正該設斷點的地方。

以SEO顧問的角度長期看網頁設計提案，常見的落差是「斷點規劃」這一項寫得像有做，實際上只是套用某個範本框架的預設數字，從沒有真的核對過業主自己網站的內容在哪個寬度會出問題。這種做法在多數情況下堪用，因為前面表格列的那些區間本來就是業界長期驗證出的合理範圍；但如果你的網站有比較特殊的版面，例如很長的產品規格表、多欄比較卡片、複雜的預約流程表單，套用別人的斷點就很可能剛好漏掉你自己內容會卡住的那個寬度。

實務做法建議是：先用最小螢幕寬度把內容設計出來，再把瀏覽器視窗慢慢拉寬，拉到版面開始不好看、不好讀的那個寬度，就在那裡設一個斷點，而不是先射箭再畫靶，直接套一組現成數字了事。這種由小到大、逐步疊加樣式的做法，業界稱為mobile-first（行動優先），跟反過來從桌機版往小螢幕砍的desktop-first做法比，目前是比較主流的做法，畢竟多數流量本來就先從手機進來。Google官方也建議採用響應式設計，因為同一網址、同一份HTML的架構相對容易實作與維護，這跟Google目前以行動版內容為索引依據的mobile-first indexing政策，也是同一個方向。

viewport設定沒寫對，前面的斷點規劃全部沒用

在深入CSS語法之前，有一個經常被忽略、但一旦漏掉會讓所有斷點規劃直接失效的前提條件：viewport meta tag。這是寫在網頁HTML最前面的一行設定：

“` <meta name=”viewport” content=”width=device-width, initial-scale=1.0″> “`

`width=device-width`這段的意思是「用裝置實際的螢幕寬度顯示頁面」，`initial-scale=1.0`則是設定頁面一開始的縮放比例為1比1，不做額外縮放。這一行只有幾十個字元，卻是RWD能不能正常運作的先決條件，順序上應該排在所有斷點設計之前確認。

CSS Media Query怎麼寫？看懂語法邏輯，不用自己寫也要看得懂

就算你不是工程師、不會自己寫程式，理解media query的基本邏輯，也能幫助你在跟廠商討論規格時聽得懂對方在講什麼。根據Mozilla開發者官方文件（MDN）的定義，media query是一段條件式，讓瀏覽器依照螢幕寬度等特徵，決定要不要套用某一組CSS樣式。基本寫法長這樣：

“` @media (min-width: 768px) { /* 螢幕寬度大於等於768px時，套用這裡的樣式 */ } “`

`min-width: 768px`這句話的意思是「螢幕寬度只要達到768px以上，就套用這段樣式」。這就是前面提到的mobile-first寫法：先寫好手機版的基本樣式，再用一個個`min-width`往上疊加平板、桌機的加強樣式，螢幕越寬套用的樣式越多。反過來的desktop-first寫法則會用`max-width`，先寫桌機版樣式，再往下用「螢幕寬度小於某個值」去覆蓋、簡化版面。你不需要自己寫這段程式碼，但看懂`min-width`與`max-width`的差別，跟廠商討論「這段用哪種寫法」時才不會完全狀況外。

兩種寫法最終呈現的畫面可以一樣，差別在維護邏輯：mobile-first通常程式碼比較精簡，因為手機版的基本樣式最少、疊加規則清楚。這也是為什麼多數新專案傾向用mobile-first。至於更新的技術，根據MDN的說明，CSS Container Query是把「依螢幕寬度決定樣式」改成「依某個容器區塊本身的寬度決定樣式」，適合版面元件會被放進不同大小容器裡重複使用的情況，例如同一張卡片元件，有時放在寬版主欄、有時放在窄版側欄。目前主流瀏覽器已支援，但屬於進階做法，不是多數中小企業網站現階段的必要條件。

圖片也要跟著斷點走，不然尺寸設計只做了一半

斷點解決的是版面排列的問題，但很多人會忽略一件事：就算版面斷點設計得再精準，如果圖片沒有跟著螢幕寬度調整檔案大小，手機使用者還是可能下載到一張為桌機準備的大尺寸圖片，白白拖慢載入速度。Google的開發者資源web.dev也指出，桌機尺寸的圖片直接餵給手機裝置，可能會多耗用兩到四倍不必要的流量。

解決方式是同時準備同一張圖片的多種尺寸，透過HTML的`srcset`屬性讓瀏覽器依照裝置實際需要的寬度自動挑選最合適的檔案下載，而不是不管螢幕大小都載入同一張最大尺寸的圖。對非技術背景的讀者來說，記住一句話就夠：斷點規劃如果只講版面、不講圖片，等於只做了一半。

斷點設計最常見的五個錯誤

把前面的原則整理成常見的踩雷情況，方便你對照自己的網站或廠商提案：

• 平板寬度被忽略：斷點只設「手機」跟「桌機」兩段，768–1024px這段平板寬度卡在兩組樣式中間，經常出現版面又擠又空的奇怪過渡狀態。
• 斷點寫死抄某支手機：直接寫「for iPhone 13」這種針對單一機型的斷點，新機型螢幕比例一變就失準，而手機型號幾乎每年都在變。
• 斷點組數過多：設了五、六組斷點，維護成本大幅提高，卻沒有對應提升多少使用者體驗，多數網站三到四組區間已經足夠。
• 只用px不考慮文字縮放：使用者把瀏覽器文字放大到150%閱讀時，用固定px設計的版面容易在中間寬度出現斷點誤判，這也是為什麼部分前端工程師偏好搭配相對單位設計。
• 只在瀏覽器開發者工具測試：模擬器縮放的畫面跟真實手機顯示，偶爾會有落差，尤其字型渲染與觸控熱區的感覺，實機測試才看得準。

找廠商驗收時，怎麼確認斷點是真的做對，不是套模板

回到最實際的問題：你不是工程師，怎麼知道對方交付的斷點規劃是真的核對過內容，還是只套了一個範本？有幾個不需要懂程式碼也能做的檢查方式。

第一，直接用滑鼠拖拉瀏覽器視窗的邊緣，從最窄慢慢拉到最寬，觀察版面在哪些寬度切換排列方式，切換的當下畫面有沒有變擠、變空、文字有沒有突然疊在一起。第二，問對方「這幾個斷點的數字是怎麼決定的」，如果對方答得出「因為某個區塊在這個寬度會擠壓」，代表有實際核對過；如果只回答「這是我們慣用的框架預設值」，也不算不合格，但代表你的網站沒有經過客製核對，適合內容單純的網站，若你的版面比較特殊就要再確認。第三，實際用自己的手機（不只是桌機瀏覽器模擬器）打開常用的幾個頁面，尤其是表單、商品列表、比較表格這類版面複雜的頁面。

這三個檢查方式都不需要看懂程式碼，卻能幫你判斷「斷點規劃」這四個字在報價單上，到底是真的做過還是寫好看的。斷點只是手機版體驗的其中一環，如果想更完整檢查內容順序、按鈕與表單這些驗收重點，可以參考手機網站設計怎麼做的驗收整理。

常見問題