RWD 網站常見錯誤：畫面縮小不等於手機也能用
自從 Google 在 2016 年宣布將調整手機 Google 中行動版網站的搜尋結果排名 Mobile-first Indexing，各大網頁設計公司的業務人員就開始以此當噱頭、勸業主改版，因為這又是一個收費的大好機會。腳步比較遲緩的企業，也在老闆發現自己家的網站用手機打不開，而競爭對手的網站在手機上很好用，而開始提出需求將自家的網站做行動版的優化。
讓資料可以優美舒服地顯示在行動裝置的解決方案有很多，響應式網頁設計（RWD, Responsive Web Design）是其中之一。RWD 的特點是讓同一個頁面可以好好顯示在行動裝置跟電腦，不會有兩個網址，後端程式通常也不用維護兩套頁面。本文介紹一些網頁設計人員在製作 RWD 網站時常犯的失誤。
2026 補充：RWD 現在主要靠語意化 HTML、CSS Grid、Flexbox、Media Query 與 Container Query 完成。JavaScript 應該用在必要的互動，不需要為了切換手機版和電腦版，把整個排版都交給 JS。
.layout {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 18rem), 1fr));
gap: 1rem;
}
1. 把自己的裝置寬度當成所有人的寬度？
不行，RWD 不能只在自己的手機上調到剛好，就當作所有裝置都會正常。
想看網頁實際上在小螢幕上看起來如何，於是網頁設計人員就用自己的手機來預覽與修改，把網頁上的 UI 輸入框、圖文編排、文字段落，在自己的手機上調整顯示得剛剛好，覺得很完美。
但只是一場夢，用其他手機看卻跑版、跳行、內容突出螢幕外、字句斷得可怕，為什麼呢？
事實上手機螢幕尺寸、解析度與顯示比例一直在改變。iOS 陣營有不同大小的 iPhone 與 iPad，Android 廠商的客製自由度更高，還有平板、摺疊裝置、分割視窗與可調整大小的桌面視窗。不能再假設「手機就是某個固定寬度」。
假設你在寬度 480px 的手機上製作頁面，把大部分東西都設定 min-width: 400px 或固定寬度 400px 以上，那在寬度 320px 的裝置上看起來可是很慘烈的。
所以調整 RWD 網頁要記住第一個原則，買一支跟老闆和客戶一樣的手機，或是把老闆和客戶的手機螢幕解析度背起來……啊不是啦！
- 多用相對尺寸與最大寬度，避免到處設定固定寬度。畫設計稿時也不要把元件排得太寬。
- 減少畫面上的雜物
以 UI 來說，有時候可以用圖示、簡短標籤、即時驗證等功能，減少輸入區旁邊塞入過多提示文字或難以縮小的 UI。
但不要只靠 placeholder 取代欄位標籤，否則開始輸入後，使用者就可能忘記這個欄位要填什麼，這在很多國外 UX 研究被當成是爛設計。
如果要檢查網頁在行動裝置上長怎樣，可以利用 Chrome、Firefox、Safari 開發者工具裡的裝置模式。不過模擬器畢竟是模擬器，系統字型、虛擬鍵盤、觸控行為、瀏覽器工具列、螢幕旋轉，跟實際用手機拖曳滑動瀏覽的感覺仍有差異。
我的做法通常是先使用瀏覽器的 Device Mode，連續縮放網頁寬度與高度，觀察任一寬度會不會產生不美觀的畫面或重大操作問題，當導覽列擠不下、卡片太窄或表單開始難用時，那個位置才是需要斷點的地方。然後再用 iPad、iPhone 與 Android 手機實際走一遍重要流程。
.content {
width: calc(100% - 2rem);
max-width: 72rem;
margin-inline: auto;
}
.cards {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
gap: 1rem;
}
用錯反而會翻車：
/* 在 320px 寬的裝置一定會產生橫向捲動 */
.form {
min-width: 400px;
}
2. orientation: landscape 就是手機打橫嗎？
不是，它判斷的是 viewport 寬高關係，不是手機實際拿直或拿橫。
製作 RWD 網站最常用的技巧之一就是 CSS Media Query，讓瀏覽器碰到符合條件的媒體裝置時，執行對應的 CSS，常見條件包括 min-width、max-width、height 與 orientation。
orientation: portrait 與 orientation: landscape 常被簡化為螢幕直向或橫向。但依照規格，它描述的是 viewport 的高是否大於等於寬，或寬是否大於高。
永遠要考慮例外與故障情況。例如手機明明直立，點擊輸入框後彈出虛擬鍵盤，viewport 高度大幅縮小，就可能變成寬大於高，意外觸發 landscape 樣式。
點擊輸入框，彈出鍵盤時，可能造成手機是直的，版面卻符合 orientation: landscape。
如果真正需求是「高度不足時縮短標頭」或「空間足夠時排成兩欄」，就直接根據高度、寬度或元件容器，不要把需求都綁在 orientation。
/* 需求是高度不足，就直接查高度 */
@media (max-height: 30rem) {
.hero {
padding-block: 1rem;
}
}
/* 需求是表單容器夠寬，就查容器 */
.form-shell {
container-type: inline-size;
}
@container (min-width: 42rem) {
.form-grid {
grid-template-columns: 1fr 1fr;
}
}
用錯反而會翻車：
/* 鍵盤彈出後可能突然把表單切成不適合的橫向版 */
@media (orientation: landscape) {
.form-grid {
grid-template-columns: 1fr 1fr;
}
}
3. 使用者修改字體設定，版面還能用嗎？
RWD 網頁版面必須容許文字能被放大、換行與增加行距。例如隨著螢幕寬度不同，標題 slogan 的「一二三四 五六七八」，有可能六七八會換到第二行，如果背景有圖案也要跟著擴大，不能永遠只預設它永遠只顯示一行，假裝畫面只在預設字級下看起來整齊。
為了避免單一個字在自己一行，CSS 可以設定 text-wrap: pretty，但實務上中文反而有時候又會覺得怪怪的，當只有一個字掉下去，我們可以知道是版面不夠寬，但如果像這種例子
我們一起去看極光旅
行吧
有其他字跟著到下一行，但又不是一個「詞」，有時候會覺得這編排換行閱讀起來很不順，因此很多情況可能還是需要手動調整。
還有一種常見的錯誤，在文字段落或容器設定固定高度 height:30px，讓區塊不論內容多寡，都顯示成一樣高。但在 RWD 的世界內，使用者可能反應「兩行字疊在一起」「字顯示到一半就被吃掉」，自己測試卻沒有問題，到底為什麼？
資訊產品的螢幕尺寸很多，而且通常可以調整文字大小、頁面縮放、背景色、文字顏色或高對比模式。問題經常就出在「自訂顯示文字大小」。
華碩瀏覽器。
Chrome for Android。
一些瀏覽器有字型縮放或最小字型大小設定，可能將整個頁面的文字放大，或把小於特定尺寸的字強制放大。如果版面把行高和容器高度鎖死，就容易出現文字重疊或內容被裁掉。
要降低這類問題：
- 行距不要鎖成過小的固定
px - 文字容器不要設定固定高度
- 不要為了卡片看起來一樣高，到處使用
overflow: hidden - 不要強迫停用瀏覽器縮放
- 不要把重要文字做成圖片
以前可能聽過用 pt 設定 font-size，或用 transform: scale() 把放大的字縮回去。但這些方法不是在解決問題，只是在和使用者的閱讀需求和裝置設計對著幹。
能隨意放大才是體貼使用者的行為。美觀只是一回事，能讓使用者看清楚網頁要傳達的訊息才是真的。
有時候也會碰到「這邊的文字斷行多落了一個字」「不能設定一行固定多少字嗎？」「文字尺寸要跟設計稿完全一樣」之類的需求。但裝置寬度、字型、語言與使用者設定都會改變，網頁不是印刷品，不能依靠手動換行固定每一行的位置。
也許在某種螢幕寬度時斷行剛剛好，但是換到手機上閱讀就亂七八糟。
如果電子刊物堅持固定版面，使用者在手機上就必須一直縮放、平移，體驗非常差。內容若沒有獨一無二，操作又很痛苦，就很難留住使用者。
還有一種作法，就是我們把 font-size 設定成某種 vw+rem 單位的，這樣就可以實現文字直接跟著 viewport 寬度放大縮小。然後在搭配 clamp，將某些範圍的字體大小給一個值，直接一行解決，而不用寫好幾套 media query css。
html {
font-size: 100%;
}
body {
line-height: 1.6;
}
.card__title {
font-size: clamp(1.125rem, 1rem + 0.5vw, 1.5rem);
}
4. 電腦好用的輸入元件，手機也好用嗎？
不一定，滑鼠容易操作的小日曆、自動完成選單與 modal，在手機上可能擋住畫面、難以點擊或被鍵盤遮住。
現代網頁程式常有小日曆、自動完成、離開輸入框後驗證、彈出訊息與 modal 等輔助輸入元件。
如果沒有處理行動裝置版面，輕則畫面出現多餘功能或浪費伺服器請求，嚴重時操作元件會擋住主要畫面，警示訊息顯示在畫面外，讓使用者無法完成流程。
自動完成選單在手機上可能很難點選。
一些舊式日曆元件在手機上較難點擊，可以評估改用瀏覽器原生日期輸入。
以前常用 User-Agent 判斷 Android、iPhone，再銷毀 jQuery UI datepicker：
if (/Android|iPhone|iPad|iPod/i.test(navigator.userAgent)) {
$('#date').datepicker('destroy');
$('#date').prop('type', 'date');
}
這種做法的問題是裝置名稱與操作能力不是同一回事。iPad 可以接滑鼠，Windows 筆電可以有觸控螢幕，同一台裝置也可能同時使用鍵盤、觸控板與手指。
使用系統 UI 元件的缺點，是不同系統的顯示方式不一樣，甚至有些合約驗收標準要求畫面和設計稿完全一致，容易造成麻煩。但只要功能與可用性一致，外觀不必每台裝置都一模一樣。
由上至下：Safari、Android Browser、Chrome on Android。
input 使用正確的 type、inputmode 與 autocomplete，可以叫出較適合的鍵盤，也能讓密碼管理器與系統自動填寫功能正常運作。
<label for="phone">手機號碼</label>
<input
id="phone"
name="phone"
type="tel"
inputmode="tel"
autocomplete="tel"
>
<label for="code">驗證碼</label>
<input
id="code"
name="code"
type="text"
inputmode="numeric"
autocomplete="one-time-code"
autocapitalize="off"
autocorrect="off"
>
表單不能只測「能不能輸入」，還要測鍵盤彈出後，送出按鈕、錯誤訊息與目前欄位是否仍看得到。modal 不要鎖死固定高度，內容區要能捲動。
.dialog {
width: calc(100% - 2rem);
max-width: 36rem;
max-height: calc(100vh - 2rem);
overflow: auto;
}
@supports (height: 100dvh) {
.dialog {
max-height: calc(100dvh - 2rem);
}
}
dvh 與 iOS Safari 的細節可延伸閱讀：
5. 行動裝置沒有瀏覽器相容性問題嗎？
當然有，IE 退役不代表 Safari、Firefox、Android WebView 與 App 內嵌瀏覽器會同時支援所有功能。
經驗豐富的網頁設計師通常都熟知 CSS hack、conditional comment 等舊式相容方法。以前同一段符合標準的語法，可能在 IE6、IE7、IE8、相容性模式、Firefox、Chrome、Safari、Opera 與各種套殼瀏覽器產生不同結果。
後來手機與平板出現，網頁環境再次往前推進，不能再一直用「IE 不支援」當作拒絕新技術的理由。但新的問題變成：Safari 何時支援？使用者的 iOS 能不能升級？Android App 裡的 WebView 有沒有更新？LINE、Facebook 或其他 App 內建瀏覽器會不會又有不同結果？
不要針對瀏覽器名稱寫一大堆 regex 去比對功能，近代瀏覽器可以優先使用 @supports、原生能力檢查與漸進增強；測試範圍則依實際流量、商業風險和使用者裝置決定。
.cards {
display: block;
}
@supports (display: grid) {
.cards {
display: grid;
grid-template-columns: repeat(3, 1fr);
gap: 1rem;
}
}
if ('ResizeObserver' in window) {
const observer = new ResizeObserver(updateLayout);
observer.observe(document.querySelector('.widget'));
}
更多 Safari 相容性案例可見 IE 退役了又怎樣？10 個 Safari 或 Firefox 的網頁瀏覽器相容性問題。
用錯反而會翻車：
/* Chrome 有支援，不代表每個瀏覽器都有 */
const observer = new ResizeObserver(updateLayout);
observer.observe(document.querySelector('.widget'));
斷點一定要跟著裝置型號嗎？
不用，斷點應該跟著內容何時無法正常閱讀或操作，而不是跟著產品發表會增加。
常見做法是在設計稿先固定 375px、768px、1440px 三張畫面，接著把所有元件硬塞進三個斷點。但真實使用者可能開分割視窗、瀏覽器側欄、摺疊裝置，或只是把桌面視窗縮到 900px。三張設計稿之間的寬度仍可能出問題。
可以從 mobile-first 的基本樣式開始，只有當內容需要更多空間時才增加欄位：
.product {
display: grid;
gap: 1rem;
}
@media (min-width: 48rem) {
.product {
grid-template-columns: minmax(0, 1fr) minmax(18rem, 0.7fr);
}
}
反向操作案例：為每款手機新增一條 Media Query，最後同一個元件被十幾條規則覆蓋。改一個 padding，就開始玩 CSS 權重與順序猜謎。
元件只看整個螢幕寬度夠嗎？
不夠，同一個元件放在主內容、側欄或 modal 時，真正可用的空間完全不同。
傳統 Media Query 只能知道 viewport 寬度。假設在 1440px 桌面上，卡片被放進只有 280px 的側欄，@media (min-width: 1024px) 還是會判定它在大螢幕，然後硬排成橫向版。
Container Query 可以讓元件根據自己的容器寬度切換版面：
.card-shell {
container-type: inline-size;
}
.card {
display: grid;
gap: 1rem;
}
@container (min-width: 32rem) {
.card {
grid-template-columns: 10rem minmax(0, 1fr);
}
}
反向操作案例：所有元件都共用同一組 viewport breakpoint，結果卡片在主欄正常，搬到側欄後圖片和文字互相擠壓。
手機、平板就一定沒有滑鼠嗎？
不一定，平板可以接滑鼠或觸控板，筆電也可能同時具有觸控螢幕。
把「手機」等同於觸控，把「電腦」等同於滑鼠，會讓混合輸入裝置陷入尷尬。例如選單只有 :hover 才能打開，觸控使用者進不去；反過來只監聽 touchstart，接上滑鼠又可能無法操作。
應先讓點擊與鍵盤操作成立，再把 hover 當成額外效果：
.menu-button {
min-width: 44px;
min-height: 44px;
}
@media (hover: hover) and (pointer: fine) {
.menu-link:hover {
text-decoration: underline;
}
}
document.querySelector('.menu-button').addEventListener('click', (event) => {
const expanded = event.currentTarget.getAttribute('aria-expanded') === 'true';
event.currentTarget.setAttribute('aria-expanded', String(!expanded));
});
實際測試可延伸閱讀 iPadOS 讓 iPad 可以接滑鼠了，游標偵聽事件能用了嗎？。
反向操作案例：導覽列的第二層選單只能靠滑鼠停留展開，觸控和鍵盤使用者都看得到入口，卻永遠點不到裡面的頁面。
圖片設成 width: 100% 就完成了嗎？
沒有，圖片還要避免下載過大的檔案、版面位移與不正確裁切。
只有 max-width: 100% 能避免圖片超出容器，但手機仍可能下載一張桌面用的 3000px 大圖。圖片如果沒有寬高資訊，載入後還會把下面內容往下推，造成 CLS。
<img
src="/images/product-800.webp"
srcset="
/images/product-480.webp 480w,
/images/product-800.webp 800w,
/images/product-1440.webp 1440w
"
sizes="(min-width: 64rem) 50vw, 100vw"
width="1440"
height="960"
alt="產品操作畫面"
loading="lazy"
>
img {
max-width: 100%;
height: auto;
}
反向操作案例：為了手機版只加 width: 100%，但仍下載 8MB 的桌面 Hero 圖；畫面看起來有縮小，使用者的等待時間和流量沒有縮小。
長網址、表格和程式碼為什麼撐破版面？
因為 RWD 不只要處理一般段落，還要處理不會自然換行的內容。
長網址、錯誤訊息、程式碼、表格、iframe，以及 Flex 或 Grid 子元素預設的最小內容寬度，都可能讓整頁出現橫向捲動。
.content {
overflow-wrap: anywhere;
}
.content pre,
.table-scroll {
max-width: 100%;
overflow-x: auto;
}
.grid-child {
min-width: 0;
}
.content iframe {
max-width: 100%;
}
表格不一定要全部改成卡片。若欄位之間必須橫向比較，可以保留表格語意，外面加一層可捲動容器：
<div class="table-scroll" tabindex="0" aria-label="可水平捲動的方案比較表">
<table>
<!-- 表格內容 -->
</table>
</div>
反向操作案例：直接替整個 body 設定 overflow-x: hidden。橫向捲動看似消失，其實只是把超出去的按鈕或文字一起切掉，問題仍然存在。
瀏海和螢幕圓角要另外處理嗎？
全螢幕介面、底部固定按鈕與橫向模式需要注意安全區域，一般文章內容則不必到處亂加 padding。
當頁面使用 viewport-fit=cover 延伸到整個螢幕，重要操作不能緊貼瀏海、動態島、Home Indicator 或圓角邊緣。
<meta
name="viewport"
content="width=device-width, initial-scale=1, viewport-fit=cover"
>
.fixed-actions {
padding-right: calc(1rem + env(safe-area-inset-right));
padding-bottom: calc(1rem + env(safe-area-inset-bottom));
padding-left: calc(1rem + env(safe-area-inset-left));
}
相關歷史與實測可見 瀏海螢幕又來了，網頁設計人員準備好迎接痛楚了嗎？。
反向操作案例：全站所有容器都加 safe-area-inset-left 與 safe-area-inset-right，結果一般直向頁面平白多出不一致的左右空白。
RWD 做好，手機就一定好用嗎？
不一定，RWD 只是排版基礎，速度、觸控目標、焦點順序、錯誤訊息與遮罩層都會影響使用者能不能完成任務。
一個網站可以完全沒有橫向捲動，卻仍然存在以下問題：
- 按鈕太小或彼此距離太近
- sticky 廣告擋住送出按鈕
- modal 打開後焦點跑到背景
- 手機版把重要功能直接隱藏
- 載入後元件位移，讓使用者點錯
- 動畫太多，低階手機操作延遲
最基本的操作尺寸與動態偏好可以先這樣處理：
button,
.button {
min-height: 44px;
padding-inline: 1rem;
}
@media (prefers-reduced-motion: reduce) {
*,
*::before,
*::after {
scroll-behavior: auto !important;
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
}
}
反向操作案例：為了讓手機畫面乾淨，把原本可以結帳、篩選或聯絡的按鈕用 display: none 隱藏，最後版面通過驗收，轉換率卻一起消失。
RWD 該怎麼測才不會漏掉問題？
不要只截三張圖比對設計稿，應該用不同寬度、不同輸入方式與真實流程測試。
最低限度可以包含：
- 從 320px 到桌面寬度連續拖曳，不只測幾個預設裝置
- 直向、橫向與高度很低的視窗
- 瀏覽器 200% zoom、系統大字級與長文字
- 虛擬鍵盤開啟後完成整份表單
- 鍵盤 Tab、滑鼠、觸控與螢幕閱讀器的基本操作
- iOS Safari、Android Chrome、桌面 Chrome、Firefox 與 Safari
- LINE、Facebook 等實際流量較高的 App 內建瀏覽器
- 慢速網路與低階裝置，確認版面載入時不會大幅位移
CSS 可以先放一個開發期用的除錯樣式，協助找到撐破頁面的元素：
/* 只在開發環境使用 */
* {
outline: 1px solid rgb(255 0 0 / 0.15);
}
反向操作案例：只用桌面 Chrome 的裝置模擬器看首頁，沒有真的在手機輸入、捲動、開選單與送出表單，最後問題全部由正式環境的使用者代測。
結論：RWD 不是把畫面縮小
RWD 的目標不是讓設計稿在幾種尺寸下看起來一模一樣，而是讓內容和操作在不同空間、字級、瀏覽器與輸入設備下仍然可用。
真正容易出錯的地方，通常不是少寫一條 Media Query，而是過度相信自己的裝置、固定尺寸、設計稿與測試環境。先讓 HTML 有合理結構，讓 CSS 可以自然換行與重排，再逐步增加 Grid、Container Query、hover 效果或全螢幕介面，會比先做一張完美的桌面圖，再努力把它塞進手機穩定得多。