RWD 是什麼？2026 響應式網頁設計原理、優缺點與常見問題 RWD 是什麼？2026 響應式網頁設計原理、優缺點與常見問題

同一個網頁，三種畫面

RWD 的全寫是 Responsive Web Design，中文一般稱為響應式網頁設計：同一個網頁會按瀏覽器的可用寬度自動改變排列，例如文章在手機疊成單欄，到了電腦可能展開成多欄，各個畫面載入的是同一份內容、同一個網址。MDN Web Docs 對它的定位寫得明確，RWD 是一種設計方法，不是某一件軟件或單一技術，而是以彈性版面應對不同裝置尺寸的一整套做法。

這裏的「寬度」指瀏覽器視窗的可用空間，不是螢幕的物理尺寸。同一部平板直向與橫向的可用寬度不同，電腦上只開半屏的視窗又是另一個數值，版面回應的是這個空間。

寬版：每日預報橫向並排

較窄版：每日預報改為逐行排列

窄版：預報逐行排列，欄內資料亦會換行

響應式與固定版面的差別

固定版面把頁面寬度寫死，例如一律 960 像素。可用空間比它窄，內容便放不下，出現橫向捲動；比它闊得多，大螢幕兩邊就留大片空白，內容只佔中間一條。

MDN Web Docs 提醒過一個容易被忽略的事實：網頁文字本來就會自動換行，真正不讓位的是設計者加入的固定尺寸元素，寫死寬度的圖片、欄位與表格。RWD 針對的正是這一層，令所有元素按可用空間調整，而不是假設每個訪客都用同一種螢幕。

流動式佈局：欄位隨空間伸縮

固定版面用像素寫死欄寬，流動式佈局（fluid grid）改用百分比這類相對單位，欄位的實際寬度跟着容器計算：容器闊，主欄就分到三分之二；容器收窄，主欄按比例縮小；到放不下兩欄時，索性疊成單欄。畫面由「縮小」變成「重排」，就在這些位置發生。

現代瀏覽器的 CSS Grid 與 Flexbox 把這件事做得相當直接：透過相應設定，格線可以按容器的空間決定欄數，並排的卡片在空間不足時自動換行。假設一間婚禮攝影工作室的作品集，在電腦上一行放四幅，平板放三幅，手機放兩幅，全部來自同一份頁面設定，不需要為每個尺寸另做一頁。

斷點按內容設定，不按裝置型號

版面何時疊上、何時展開，一種常見做法是用媒體查詢（media query）：按瀏覽器視窗的寬度套用另一組樣式，切換的那條界線叫斷點（breakpoint）。另一種做法是上一節提到的 Grid 與 Flexbox 佈局，這類佈局在空間不足時會自行換行。兩種做法經常配合使用。

Google web.dev 對斷點的建議只有一個方向：按內容設定，不要按裝置型號。手機型號年年更新，跟着型號走永遠追不完；跟內容走才穩定，由最窄的版面開始，逐步拉闊視窗，見到一行文字變得太長、讀起來吃力，或者欄位之間撐出大片空洞，就在那個寬度設斷點。同一個網站內不同頁面用不同斷點，也是正常做法，因為各頁的內容密度本來就不同。

斷點還有一條底線：空間不夠時，不應靠刪走重要內容解決。Google web.dev 講得直白，螢幕尺寸決定不了用戶需要哪項資訊；手機訪客要的不是「精簡版」，而是同一份資訊的另一種排法。

媒體查詢按寬度切換欄數；圖中的斷點數值只作示例

彈性圖片：顯示縮小與下載變小是兩回事

彈性圖片（flexible images）的第一步，是用 CSS 限制圖片的顯示寬度，例如「最闊不超過容器」，大圖在窄螢幕上便會自動縮小顯示，版面不會被撐破。

Google web.dev 指出，CSS 管制的只是顯示尺寸，瀏覽器下載的仍然是原本那個檔案：假設一張 2,000 像素闊的相片，在手機上顯示成 400 像素闊的縮圖，流量一點不少。要減輕負擔，可以為同一張圖準備幾個尺寸的版本，在 srcset 以寬度描述符列明，再配合 sizes 說明圖片的預期顯示寬度，讓瀏覽器按顯示尺寸與像素密度等條件選擇下載哪一份；這是按條件選圖，不保證手機一定拿到最小的檔案。圖片檔案本身要壓到多小、用什麼格式，屬於圖片優化的範圍，可以看〈5 招網站圖片優化〉的具體做法。

另一個影響觀感的細節是預留空間：在圖片載入前先標明它的寬高（與圖片比例相符），瀏覽器就會預先留出位置，減少圖片到達時把下方內容推下去的移位。Google web.dev 把這列為基本做法，處理的正是圖片引起的版面跳動。

手機優先，由最窄的版面開始排

同一份內容，兩種起步都可以做出好的 RWD：先排電腦版再照顧窄螢幕是一種；先排手機版、定好最窄空間的內容次序，到較大螢幕才調整欄位排列，是另一種。後者稱為手機優先（mobile first），是設計次序上的選擇，也是 Google web.dev 建議的次序：在空間最有限的版本裏先講清楚內容的主次，之後每一級放寬，都是在已定的次序上調整排列，而不是刪走資訊。

次序之所以關鍵，在於手機版的空間通常只夠直排，內容次序就是讀者見到的次序。假設診所網站的訪客是為了預約或查地址而來，一段放在最前的機構沿革，就會把這些資訊推到兩三屏之外；這個安排在電腦的多欄版面上，未必看得出問題。

手機優先：按訪客需要安排內容次序，讓預約及地址更容易找到

所有裝置共用一份內容

RWD 對訪客的直接好處，是不論用手機、平板還是電腦，各裝置載入的都是同一份內容。在手機上看到一半的文章，回到電腦打開同一條連結，內容完整在前；分享連結給客人，也不必先問對方用什麼裝置開。

「同一份內容」講的是來源，不保證每個尺寸都完整顯示。Nielsen Norman Group 就觀察到，實際的響應式網站仍可能省略手機版的功能或內容；訪客在你網站的每個裝置上實際見到什麼，要靠檢查確認。

維護集中在一份內容

網站若分開手機版與電腦版，即使兩邊共用同一個內容系統，版面仍要分別照顧：改一次價錢，就要分別檢查兩套版面的呈現，漏查一版，客人見到的資訊就可能不一致。RWD 只有一套版面，隨寬度重排，通常省掉分別檢查兩套版面的工夫；對餐牌、課程表、活動頁這類經常變動的內容，分別最實在。

省掉同步工夫，不等於可以少檢查。RWD 的更新同樣要在不同裝置上複查，而且上傳一張過闊的圖片，該頁在多個裝置上都有機會受影響，因為大家載入的是同一份頁面。

版面與效能之間的取捨

設計上，同一個版面要由最窄照顧到最闊，每一區都要預想它在不同寬度下的樣子，跨尺寸的設計與測試是實實在在的投入；一些依賴精確位置的構圖，也可能要為此另做安排。

資源是另一個要盯的位置：若仍向手機供應超出需要的大圖，就會增加下載負擔，多尺寸版本是改善方法之一，但要逐項準備、設定得當。載入表現不會因為「響應式」三個字自動變好，它是另一組要分開處理的工作。

企業頁面構圖參考：圖片、文字與案例區域都需考慮窄螢幕的排列

RWD 與 AWD：流動與預設版面的分別

與 RWD 相提並論的常是 AWD（Adaptive Web Design，自適應網頁設計）。這個詞在不同文章的用法並不統一，本文取「預設版面」的講法來比較：AWD 預先做好幾個固定寬度的版面，螢幕落入哪個範圍，就套用哪一套，Joni Korpi 示範的正是這種切換策略。AWD 換來的，是每個預設版面可以為該尺寸精細調整。RWD 的欄位則隨空間伸縮，斷點之間的過渡較連續，但遇上斷點同樣會跳變，也不保證每個尺寸都有合用的排列。

比較時要先確認對方講的 AWD 是哪一種。Nielsen Norman Group 用 adaptive 一詞時，指的是伺服器按裝置提供不同內容，與本文「多個預設寬度版面」的用法不同；術語未統一，先問清楚再下判斷。

網址架構是另一回事

「單一網址」常被當成 RWD 的標記，其實網址與 HTML 的供應方式是獨立的架構選擇。Google Search Central 把手機版配置分為三種，對應關係如下：

見到 m. 開頭的手機網址，要再確認桌面版是否以另一個網址供應同一頁：若是，該站至少有部分配置屬於獨立網址；反過來只見一個網址，也不能就此斷定網站採用響應式設計，因為動態服務同樣用單一網址。判斷架構看的是網址與 HTML 的對應關係，不是名稱本身。

斷點之間的縫隙

螢幕尺寸是連續的，斷點是離散的。設計時驗過手機與桌面兩個寬度，中間仍有無數狀態：平板直向、大螢幕手機橫向、電腦上只開半屏的視窗，每一段都可能是版面設計時沒想過的尺寸。

橫向滾動是這類縫隙的典型病徵之一，成因可以很具體：一段寫死寬度的表格、一張沒設上限的圖片、一行不容斷開的長字串。這些元素在斷點之間沒驗過的尺寸最容易露出問題。元素超出所在容器時，若頁面沒有為它安排局部捲動一類的處理，整頁便可能被撐出橫向捲動，找出那一項，比懷疑整個網站來得有效。

畫面適配了，手指未必好用

版面顯示正常，不等於操作正常。Nielsen Norman Group 的文章提醒，一套實作能夠跨裝置呈現，不代表介面在每種裝置上都合用；桌面滑鼠點得準的位置，換成手指就可能是另一回事：觸控目標太細、按鈕太近、需要精準滑動的操作，在手機上可能增加誤觸或操作困難。

操作層的差距還包括位置。單手操作時，按鈕是否容易觸及，要看握法與手機尺寸；雙手或橫向操作，情況又不同。畫面適配解決「看得到」，按鈕放哪裏、多大、間隔多遠，這些判斷不會隨響應式自動出現，要逐個裝置試出來。

內容更新帶來的新問題

網站交付時手機版正常，問題可以在之後才出現：新通告配了一張大圖、產品頁貼上供應商的規格表、同事在標題位置加了一行宣傳字句。每一項都是對響應式版面的新測試，交收那一刻驗證過的，只是當時的內容。

Nielsen Norman Group 的提醒在此適用：維護一套內容可減少多版本同步的工作，但介面有變更，仍要跨裝置檢查。編輯多數在電腦上更新、也在電腦上預覽，只看桌面預覽便可能漏查手機上的情況；內容更新後用手機複查一次，不是額外工序，而是常規步驟。

先選對要測的頁面

初步檢查不必逐頁掃，先排優先次序，由代表性頁面着手：首頁、查詢或落單的頁面、最長的一篇內容頁，再加一個有表格或大圖的頁面。表格與大圖正是撐破版面的典型來源，這幾頁有助先暴露這類問題；其餘頁面之後仍可逐步補測。

尺寸方面，常用的起點是三個寬度：一個手機寬度、一個平板寬度、一個桌面寬度。起點之外，記得在兩個斷點之間拖一拖：問題可以藏在設計時沒想過的中間尺寸裏。

瀏覽器模擬與真實裝置各測什麼

桌面 Chrome 的開發者工具（DevTools）內置裝置模式：開啟後可以選手機型號、直接拖動畫面邊緣改變寬度，並顯示頁面的媒體查詢斷點。Chrome 官方文件也講明，模擬只是近似：程式始終在桌面電腦上運行，觸控反應、硬件速度與網絡環境都與真機不同，結果只能作參考。

瀏覽器的裝置模式適合檢查不同寬度下的版面，例如橫向捲動、欄位排列錯誤或圖片過大。檢查時可逐步調整視窗寬度，留意問題在哪個位置出現，再用手機實際測試操作流程與載入速度。有其他裝置時，也可以比較顯示和操作上的差異，方便跟進。

查詢與落單流程要親手走一遍

顯示檢查完，輪到操作。最直接的方法，是把自己當成客人：由進站到送出查詢或完成落單，完整走一次。過程盯的是動作而非畫面，表單欄位用手指按會不會按錯、鍵盤彈出時會不會蓋住正在填的格、提交按鈕看得到又按得到嗎、送出後有沒有清楚的成功提示。

網店的話，付款前的每一步都要加測：加入購物車、填地址、選付款方式，每一步都用同一部手機走完，中途遇到的每個阻滯都記下來。

問題要記錄，修正後要複測

檢查發現的問題，憑記憶轉述容易失真：「手機上看不清楚」這種講法，接手的人無法重現。一條可用的記錄要齊四項：出事頁面的實際網址、當時的視窗寬度或裝置型號與瀏覽器、做了什麼動作、見到什麼現象。格式例如下：

上表只是格式示例，各欄按你網站的實際頁面與裝置填寫，能記下精確寬度或型號就不要只寫「手機」。交給設計或開發跟進後，用記錄裏的同一組條件複測：同一頁、同一寬度、同一動作；條件不同，結果不可比。確認修正無誤，該條記錄才劃掉，其後每次大改內容，再把同一批頁面掃一遍。

問題清單整理好，仍分不清哪些屬版面設定、哪些屬內容安排？可以把清單交給 BINGO，先商議檢查範圍與修改報價，這類修改多數屬於網頁設計服務的範圍。