響應式設計 ≠ 做幾個斷點就完事

當前響應式設計熱度極高（.net 首頁 60% 文章圍繞此），但關注禁忌比追逐技巧更有價值。Brad Frost 在 .net 雜志指出五大常見錯誤，本文補充第六條，助你避開「偽響應式」陷阱。

誤區一：以特定設備尺寸為斷點觸發佈局變化

「iPhone 寬 320px、iPad 768px、桌面 1024px」——**斷點應由內容需求決定，而非設備尺寸**。內容在何處斷裂、何處難讀，就在何處設斷點。設備尺寸無限碎片化，追著設備跑永遠跟不上。

誤區二：單一佈局試圖適配所有屏幕

Frost 指出：移動設備不僅是屏幕尺寸不同。手機有 GPS、電話、加速度計、觸控、相機……瀏覽器 API 正逐步開放這些能力。**響應式基礎上，必須用漸進增強、特性檢測調用硬件能力**，才能真正釋放多終端價值。

誤區三：忽略性能預算，桌面端資源原樣下發移動端

響應式不等於「桌面頁面縮小版」。大圖、重腳本、冗餘 CSS 在 3G/4G 下會拖垮載入速度。**必須建立性能預算**：移動端首屏 < 1s、總資源 < 500KB、請求數 < 30，並用 `srcset`、`picture`、代碼分割、Service Worker 兌現承諾。

誤區四：觸控交互只是把滑鼠事件換成 touch 事件

滑鼠有 hover、精準點擊；手指有觸控區域大小、手勢、無 hover 狀態。**觸控優化必須重新設計交互模式**：更大的點擊熱區、滑動代替懸浮、長按代替右鍵、手勢導航。別讓用戶用手指模擬滑鼠。

誤區五：以為上線就萬事大吉，不做持續的多設備真機測試

模擬器 ≠ 真機。真機的字體渲染、滾動性能、鍵盤彈出佈局重排、網絡波動、電量模式，全是模擬器給不出的驚喜。**建立真機測試矩陣（主流機型 × 系統版本 × 瀏覽器），納入發布流程強制關卡。**

誤區六（補充）：以為今天寫的代碼明天依然最佳

響應式最佳實踐**每月都在進化**：新的圖片響應方案、新的 CSS 特性（Container Queries、`:has()`、Subgrid）、瀏覽器引擎優化、新的 JavaScript 库替換舊有 hack。**每個新項目啟動前，花半天閱讀最新技術動態**；上一個項目的 hack，或許已成成熟庫。保持「半衰期意識」，拒絕技術債務固化。

給團隊的行動建議

1. 建立「響應式設計檢核表」，覆蓋斷點策略、性能預算、觸控適配、硬件能力調用、真機測試、技術更新機制。
2. 引入「設計系統」而非靜態 UI Kit，用 Token、Component、Pattern 管理跨端一致性與差異化。
3. 設置「技術雷達」例會，追蹤 CSS WG、WebKit/Blink/Gecko 釋出、社區最佳實踐演進。

響應式設計是場**持久戰**，贏家不是寫出最多媒體查詢的人，而是**建立持續進化機制**的團隊。