Figma 網格系統教學：響應式排版與 Layout Grid 完整設定指南
Figma Layout Grid 是 Figma 內建的視覺化網格系統，能在 Frame 上疊加 Column、Row或 Grid（方格）三種結構，作為元素對齊與響應式排版的依據…
Figma Layout Grid 是什麼：把設計與開發對齊的欄位契約
Figma Layout Grid 是 Figma 內建的視覺化網格系統，能在 Frame 上疊加 Column、Row或 Grid（方格）三種結構，作為元素對齊與響應式排版的依據。它跟一般對齊參考線最大的差別在於：網格是一套可命名、可套用、可跨 Frame 統一的設計系統資產，能被重複使用並寫進設計系統，這點和畫完即丟的輔助線完全不同。換句話說，它是一份欄位契約，把設計端和開發端綁在同一組數字上。官方文件把 Layout Grid 定義為「在 Frame 或元件上提供視覺引導的疊加層」，並明確支援 Column、Row、Grid 三種類型 [來源：Figma Help Center〈Guide to Layout Grids〉〈https://help.figma.com/hc/en-us/articles/360040451373〉]。
重點先看：Layout Grid 的價值不在半透明線本身，而在被鎖下來的欄數、間距、邊界與最大寬度。這組數字一旦與開發端共用，就成為貫穿設計稿與 CSS 的單一事實來源，而非畫完即丟的輔助線。
初次打開網格，畫面上只有幾條半透明直線，很容易把它當裝飾。網格真正的價值其實藏在被鎖下來的數值裡：欄數、間距、邊界、最大寬度。一旦把這些數字寫進 Frame 的 Layout Grid 設定，它就成為整個專案的排版骨架，決定每一個元件該落在哪一欄、Frame 縮放時要跟著哪一條線移動。如果你正在學 Figma 中文完整教學入門指南 裡的排版觀念，會發現網格幾乎是所有進階技巧的前置條件。
把 Layout Grid 放在設計系統脈絡下理解，它對應的是設計 token 裡的「版面層級」變數。一個成熟的設計系統會把 spacing、color、typography、layout 分層管理，網格屬於 layout 這一層的核心資產。當你在 Component Library 或 Variables 裡把網格規格化、命名化（例如 desktop-grid-12、tablet-grid-8、mobile-grid-4），任何一個設計師新增 Frame 時都能直接套用同一組數值，不需要每次重新決定欄數與間距。這種規格化帶來的穩定性，就是大型專案之所以能用同一份網格撐起數十個頁面的原因。
- Column（欄網格）：響應式介面最常用，參數包含 Count、Type、Width、Gutter、Offset。
- Row（列網格）：用於 baseline 韻律網格，控制文字行距節奏。
- Grid（方格）：8pt 或 4pt 方格，用來做像素級對齊與圖示排版。
- 網格只在設計階段顯示，不會進入匯出成品，但其數值是交付給開發的 spec 依據 [來源：Figma Help Center〈Guide to Layout Grids〉〈https://help.figma.com/hc/en-us/articles/360040451373〉]。
Column Grid 的核心參數有六個：Count（欄數）、Type（Stretch 流體或 Align 固定）、Width（欄寬）、Gutter（欄間距）、Offset（左右邊界）、Gutter on outside（外側間距）。這六個數字決定了你的網格長什麼樣、能不能響應、會不會跟開發端打架。光是把這六個參數搞清楚，就已經贏過很多直接套範本的設計稿了。對整體排版觀念有興趣的話，可以一併參考 網頁版面設計與響應式排版觀念。
把這六個參數拆開來看，每一個都對應一個開發端要承接的決策。Count 直接決定 grid-template-columns 要 repeat 幾次，Count 12 對應 repeat(12, 1fr)，Count 8 對應 repeat(8, 1fr)，兩端一旦不一致，跨欄元素就會錯位。Type 選 Stretch 時，Figma 會把欄寬交給 Frame 寬度自動計算，這對應開發端用 fr 或百分比單位；選 Align 時，欄寬被你手動鎖死，這對應開發端用固定 px 的 column。Width 在 Stretch 模式下是唯讀的，由系統算出來給你看，真正要你填的是 Align 模式下的欄寬。Gutter 直接映射成 CSS 的 gap，是設計與開發最容易對不上的數字，因為設計師習慣填 24，開發卻常寫 16 或 20。Offset 則映射成 container 的左右 padding，決定內容離 Frame 邊緣多遠。最後 Gutter on outside 這個勾選，控制第一欄之前與最後一欄之後要不要也放一條 gutter，勾起來時容器內側的留白會比較窄，外側 gutter 會吃掉部分 Offset，這在設計窄邊欄版面時要特別留意。
理解這六個參數的連動關係，比死記數值更重要。Count 與 Width 互相牽制：Frame 寬度固定時，Count 越多、單欄越窄，Gutter 也會佔掉更多空間。在 1440px 的 Frame 上填 Count 12、Gutter 24、Offset 32，扣掉左右各 32 的邊界後還有 1376px 可用，再扣掉 11 條 gutter 共 264px，剩下 1112px 平分給 12 欄，每欄大約 92px。把這個換算邏輯摸熟，你就能在開會時當場算出某個跨 4 欄的卡片實際有多寬，不用等開發端回報。這種把設計參數換算成實際像素的能力，是設計與開發能對得起來的底層功課。
從版面工程的角度看，Layout Grid 真正的角色是一致性的基礎建設。只要在 Figma 用正確的欄數、間距與斷點邊界把網格定下來，元件的響應行為、開發端的 CSS Grid、以及整個團隊的版面一致性，就都被同一份規則收斂。若你還在摸索 Figma 完整指南與介面操作，這個觀念會直接決定你之後做響應式專案會不會破圖。
設定前先決定：固定網格還是流體網格
Column Grid 有兩種模式：Stretch（流體）和 Align（固定）。選哪一個，取決於你的介面要不要隨螢幕寬度自適應。如果要做響應式 Web/App 介面，選 Stretch，欄寬會隨 Frame 寬度自動伸縮，總寬與邊界鎖死；如果要做固定寬度設計稿，或要精確對齊開發端的固定欄寬（例如 Tailwind 的 container），就選 Align 並手動指定欄寬與間距。
這一步看起來無關緊要，卻是響應式排版成敗的關鍵。把 Align 固定網格當 Stretch 用，是新手最常踩的雷：Frame 一縮放，欄位不跟著動，內容馬上錯位。實務上較穩妥的做法是要求團隊主體版面一律用 Stretch 流體網格，只有需要跟 CSS container 精確對齊的關鍵 section（例如 hero、定價表）才局部用 Align。這樣可以在保持響應彈性的同時，兼顧 spec 輸出的精確度。對響應式設計的全貌有興趣，可延伸讀 Figma 響應式設計與行動版排版 與 響應式網頁設計 RWD 基礎觀念。
| 面向 | Stretch 流體網格 | Align 固定網格 |
|---|---|---|
| 欄寬 | 隨 Frame 寬度自動伸縮 | 手動指定，固定不變 |
| 欄數 | 固定 | 可變（Frame 越寬欄數越多） |
| Gutter | 固定 | 固定 |
| 適用場景 | RWD 響應式介面主體 | 固定寬度稿、CSS container 對齊 |
| 響應行為 | 欄位跟著 Frame 伸縮 | 欄位不動，適合像素級控制 |
| 常見錯誤 | — | 誤當 Stretch 用，縮放即破圖 |
九成以上的 Web/App 響應式專案，主體都該用 Stretch。Align 留給那些「這個區塊寬度就是 1120px，一個像素都不能動」的場合，例如要跟 Landing Page 銷售頁製作教學 裡的固定容器對齊時。混淆兩者，是設計與開發對不起來的第一個原因。若你想把響應式觀念再往下扎根，RWD 響應式網頁實戰排版 和 AWD 自適應與 RWD 響應式差異 都值得一看。
桌面版 12 欄是怎麼來的
桌面版主流做法是 12 欄、gutter 設 16 到 24px、max-width 約 1200 到 1440px。12 之所以成為業界慣例，不是美感問題，是數學問題：12 可被 2、3、4、6 整除，方便同時做兩欄對稱、三欄等分、8 加 4 不對稱版面。這個因數特性讓 12 欄幾乎能組出所有常見的桌面版面結構。
舉個實際的設定組合：在 1440px 寬的 Frame 上，設 Count 12、Type Stretch、Gutter 24、Offset 32，就能得到一套多數開發端都認得的桌面網格。Gutter 與 margin 建議用 8 的倍數（16、24、32），跟間距系統以及開發端常用的 CSS Box Model 邊距與留白觀念 一致，避免設計與實作出現小數點落差。Offset 至少留 24 到 32px，避免內容貼齊螢幕邊緣造成視覺壓迫。
為什麼不是 16 欄或 8 欄？8 欄在桌面太粗，做不出細分；16 欄又太細，多數版面用不到那麼多等分，反而增加管理成本。12 剛好落在中間，兼顧彈性與可控性，這也是它成為 Bootstrap、Tailwind 等主流框架預設選擇的原因。框架的選擇本身也是排版工程的一環，想了解框架差異可參考 WordPress 視覺化頁面編輯器比較 或 Elementor 頁面編輯器完整教學。
桌面網格的重點從來就不是 12 這個數字本身，關鍵在於你能不能用同一組數值，讓設計稿、CSS 入門與響應式設計語法、開發端的容器三者對得起來。只要這組數字在兩端一致，響應式行為就會跟著一致。這也是為什麼桌面網格的數值應該寫進設計系統文件，讓它變成團隊共用的資產，不要只留在某個設計師的腦袋裡。
平板與手機的欄數縮減策略
響應式的關鍵，在於依斷點主動縮減欄數。平板常用 8 欄、手機常用 4 欄，同時把 gutter 與邊界縮小，讓觸控間距與閱讀節奏合理。把桌面 12 欄直接套到手機，欄位會窄到根本放不下內容，這是響應式破圖最常見的源頭之一。
手機優先縮減欄數的必要性，可以用一份流量結構數據佐證。根據 Statista 的全球網站流量統計，2026 年第一季來自行動裝置（不含平板）的流量占比達到 52.27%，已經過半 [來源：Statista〈Share of mobile web traffic worldwide quarterly 2015-2026〉〈https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/〉〈2026-04-28〉]。這代表當你在 Figma 設計網格時，如果把桌面 12 欄當作唯一基準、手機只是事後縮放，等於讓超過半數使用者在版面破圖的風險下瀏覽。把斷點欄數縮減視為設計階段的主動決策，才能讓網格真正回應這份行動優先的流量結構。
這份行動優先的現實，連搜尋引擎也早就跟著調整。Google 自 2020 年宣布全面導向行動優先索引（mobile-first indexing），並於 2023 年正式宣告這項遷移完成，所有能在行動裝置上運作的網站，一律以行動版檢索器作為主要收錄來源 [來源：Google Search Central Blog〈Mobile-first indexing is here〉〈https://developers.google.com/search/blog/2023/10/mobile-first-is-here〉〈2023-10-31〉]。對網格設計的直接影響是：搜尋引擎實際收錄的版本，是你手機那一組斷點網格所撐起來的版面。如果你只認真設計桌面 12 欄，手機 4 欄草草帶過，被索引與被排名的會是那個沒被好好照顧的版本。這也說明為什麼手機網格必須被當成獨立的設計產出來對待，它本身就是一套完整的排版規格，有自己專屬的欄數、間距與邊界，附屬於桌面版只會讓它失去被認真設計的機會。
實務上還有一個常被忽略的層次：斷點的 Frame 寬度要對齊開發端的 media query，否則設計稿與成品會在不同寬度切換欄數。開發端常用的 desktop 斷點落在 1024px 或 1200px，tablet 落在 768px，mobile 落在 375px 或 414px。你的 Frame 寬度最好直接採用這幾個值，避免隨意填 1300 或 800 這類不對應任何 media query 的數字。當 Frame 寬度與 media query 的觸發點一致，設計端看到的欄數切換，就會等於使用者瀏覽時實際發生的切換，設計驗收才能對得上真實使用情境。
| 裝置 | 寬度區間 | 欄數 | Gutter | 邊界（Margin） |
|---|---|---|---|---|
| 桌面 | 1200 到 1440px | 12 | 16 到 24px | 24 到 32px |
| 平板 | 768 到 1024px | 8 | 16 到 24px | 32 到 48px |
| 手機 | 414px 以下 | 4 | 16px | 16 到 20px |
欄數縮減的原則很單純：讓最小可用單位（手機的 1 欄）對應一個舒適的內容寬度。手機 4 欄時，1 欄大約是 70 到 80px，剛好容納一段正文；2 欄就能放卡片，3 欄以上就開始擠。觸控也要納入考量：手機 gutter 與可點擊區域之間要留夠間距，不然拇指一壓就誤觸隔壁按鈕。這類觸控與視覺層次的細節，可以對照 排版設計與字體行距視覺層次 一起看。
實作上，為不同斷點建立不同寬度的 Frame，各自套用對應的 Column Grid，不要用一個 Frame 硬撐全部裝置。桌面 1440 Frame 套 12 欄、平板 768 Frame 套 8 欄、手機 375 Frame 套 4 欄，每個斷點都是獨立的網格規格。如果你做的是電商或內容站，RWD 響應式電商網頁設計流程 裡也有對應的斷點規劃可以參考。順帶一提，平板的 8 欄不是硬規定，有些團隊用 6 欄也行，重點是欄寬要讓內容不擠。
這套「桌面 12、平板 8、手機 4」的遞減策略，才是響應式排版不失敗的真正關鍵。多數教學只示範「把 Grid 打開、填 12 欄」，卻沒點出網格的價值在斷點間的欄數縮減，而不在欄本身。把這個遞減邏輯寫進設計系統，比記住任何單一數字都重要。想看更多版面範例，網頁排版設計範例與圖文排列 與 Bento Grid 便當盒版面配置 都有現成的拆解。
Offset 偏移量：網格真正發揮價值的地方
Offset 是網格左右兩側的留白邊界，它有雙重角色：一是當 Frame 邊界留白，二是搭配欄位起點做內容縮排與不對稱版面。當你要做內容靠左、視覺靠右的不對稱版面，或讓某個區塊從第 3 欄開始佔 8 欄時，靠的就是 Offset 與欄位起點。這是大多數教學略過、卻最影響成品質感的一步。
Offset 在不同斷點的策略也要跟著調整。桌面 Offset 留 32px 已經足夠營造呼吸感，到了平板可以放大到 48px，因為平板螢幕離眼睛較近，外側留白要更明顯；手機的 Offset 則要收斂到 20px 左右，避免在小螢幕上浪費有限的水平空間。這組遞增與收斂的邏輯，呼應前面提到的欄數縮減策略：網格的各項參數都要依斷點重新校準，不能把桌面的數值整套搬過去。把 Offset 的斷點策略寫進設計系統，能讓三個裝置的留白節奏一致。
常見手法有兩種：一是讓主內容佔中間欄、側邊欄或留白佔外側欄，例如內容區佔 8 欄、左右各留 2 欄作呼吸空間；二是 hero 區讓標題從第 2 欄起，視覺元素跨到右側。滿版排版乍看把每個像素都用滿，實際上讀者會找不到視線要停在哪裡，按鈕和段落擠在一起反而降低點擊。外側那 2 欄留白，對應的是版面設計裡一直在講的視覺動線：讀者需要喘息的空間，才知道哪一段是重點。
Offset 的效果很難用文字傳達，非得自己在 Figma 裡拉一次才會有感。同樣一組網格數值，把內容塞滿 12 欄，與只佔中間 8 欄、外側留白，成品質感可以天差地別，差別就只在 Offset 的取捨。真正拉開差距的，往往是 Offset 取捨與斷點間的欄數縮減，欄數本身在這裡反而退居配角：欄位只負責定位，Offset 與縮減策略才決定排版的氣口。如果你常做 landing page，Landing Page 轉換率優化原則 對留白與轉換的關係有更細的討論。
把 Offset 跟 Constraints 綁在一起用，是讓響應式排版真正動起來的組合技。網格把欄位位置定下來，Constraints 決定元素在縮放時貼左、貼右還是置中。沒有 Constraints，再漂亮的網格也只是背景圖。這個觀念在前段的響應式設計操作裡有完整示範。
Layout Grid、Auto Layout 與 Constraints 怎麼搭配
這三個工具各司其職，不會打架。Layout Grid 負責整體版面的欄位定位，Constraints 負責單一元素在 Frame 縮放時怎麼跟著動，Auto Layout 負責元件內部的排列間距。用網格定位大區塊、用 Auto Layout 處理區塊內部、用 Constraints 處理響應式縮放，三者分工清楚，不需要選邊站。把它們對應到設計的三個尺度（版面、元件、響應），尺度分清楚，工具自然不會打架。
最常見的錯誤，是用 Auto Layout 硬做整頁響應式排版。Auto Layout 的強項是元件內部排列，不是跨欄位的版面骨架。把它當網格用，會失去網格的一致性，每個區塊各自為政，改一個就要連動改十個。正確的做法是分層：Frame 套網格做大版面，區塊內部用 Auto Layout 做細節排列，關鍵元素再用 Constraints 鎖住對齊。這套分層觀念在 UI 原型設計與 Wireframe 差異 裡也有對應的層級拆解。若你剛接觸這些工具，免費 UIUX 自學資源 是不錯的起點。
Constraints 的設定有幾個值得記住的邊界條件。當元素的 Constraints 設為 Left and Right，它在 Frame 縮放時會兩端都被拉開，等於填滿欄位，適合需要橫向延展的背景或分隔線；設為 Center 則元素維持原寬、只水平置中，適合標題或按鈕；設為 Scale 則元素會等比放大縮小，適合圖片，但要留意小螢幕下圖片縮太小會失去細節。把這幾種模式對應到網格的欄位，就能精準控制每個元素在縮放時的行為，而不會出現「桌面看正常、手機卻擠成一團」的落差。
換個角度想，這三者其實對應設計的三個尺度：版面、元件、響應。把尺度分清楚，工具自然不會打架。想再進階一點，搭配 UIUX 設計師常用 ChatGPT 指令 把網格 spec 寫成可交付的文件，或是用 Figma 動態按鈕與轉場動畫、Figma 載入動畫與 Loading 原型 處理元件內的互動細節，整個工作流程會順很多。元件本身的視覺質感也不能放過，像 Figma 毛玻璃霧面質感效果、Figma 互動式輪播滑塊設計、Figma 環形文字與圓弧排版、Figma 視差效果與沉浸式互動 都是常見搭配。
把網格輸出給開發，對齊 CSS Grid 與 Tailwind
把 Figma 網格的欄數、gutter、max-width 直接映射成開發端的 grid-template-columns 與 container 設定，兩邊用同一組數值，設計稿的 12 欄就會等於開發端的 12 欄。這聽起來理所當然，卻是絕大多數專案設計與開發對不起來的根本原因：兩端各自憑感覺填數字。
| Figma 網格參數 | 對應的開發端設定 | 說明 |
|---|---|---|
| Count（欄數） | grid-template-columns 欄數 | 例：repeat(12, 1fr) |
| Gutter | gap | 例：gap: 24px |
| Offset / max-width | container padding 與 max-width | 例：max-width: 1200px; padding: 0 32px |
| 斷點（1440/768/375） | media query | 對應 desktop / tablet / mobile |
| Tailwind 對齊 | grid-cols-12 + gap-x-* | breakpoint md/lg/xl 對應各斷點 Frame |
Tailwind 的對齊方式很直覺：grid-cols-12 加上 gap-x-*，再用 md、lg、xl 等 breakpoint 對應 Figma 各斷點的 Frame。CSS Grid 官方文件對 grid-template-columns 與 gap 有完整定義 [來源：MDN Web Docs〈CSS Grid Layout〉〈https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout〉]，Tailwind 官方文件也列出 grid-cols 與 gap 的對應關係 [來源：Tailwind CSS 官方文件〈Grid Template Columns〉〈https://tailwindcss.com/docs/grid-template-columns〉]。Figma 的 Dev Mode 會顯示網格資訊，但我仍建議在設計系統文件把數值寫死，不要只靠 Dev Mode，因為 Dev Mode 偶爾會漏掉 Offset 這類細節。
最常見的落差是：設計用 Stretch 流體網格，開發卻寫固定 px 寬度，結果中間寬度（例如 960px）的版面兩邊就是對不齊。流體網格的精神是欄寬浮動、總寬與邊界鎖死，開發端若沒跟著用 fr 單位或百分比，就會破這個契約。這個落差是可以算出來的：以 12 欄、gutter 24px 的設計為例，若開發端把 gap 寫成 16px，11 條 gutter 合計就少了 88px，整組欄位的可用總寬會比設計稿縮減約 6%，跨欄卡片的右邊界因此集體往左擠，這種累積誤差在首頁多卡片排版時會一眼被看出來。交付時建議附一張斷點對照表，把欄數、gutter、max-width、邊界一次列清楚，開發拿到就能直接照抄，不用再回來對數字。這張表也可以順手整合進 SASS SCSS 預處理器加速開發 的變數系統，讓設計 token 直接變成程式碼變數。
只要設計端的欄數、gutter、max-width 與開發端的 grid-template-columns、gap、container 用同一組數值，Figma 的 12 欄就會等於開發端的 12 欄，響應式行為才會一致。前端框架本身的版面能力也值得摸熟，像 Bricks Builder 視覺化編輯器教學、Divi 主題架站與網頁設計 都會用到格線系統，觀念互通。
從零搭建一套桌面到手機網格：步驟拆解
把前面幾個觀念串起來，這裡用一份完整的設定流程把網格從零搭到能交付。流程鎖定三個裝置：桌面 1440px、平板 768px、手機 375px。每一步都對應一個明確的 Figma 操作與一個要寫進設計系統的數值。
- 建立三個獨立 Frame：在 Figma 直接新增三個 Frame，寬度分別設為 1440、768、375，高度依內容決定。一個 Frame 對應一個斷點，避免用單一 Frame 硬撐全部裝置。
- 桌面 Frame 套 12 欄流體網格：選 Frame，右側面板按 Layout Grid 的加號，類型選 Column，Count 填 12，Type 選 Stretch，Gutter 填 24，Offset 填 32。這組數值對應桌面主流網格。
- 平板 Frame 套 8 欄網格：同樣新增 Column 網格，Count 填 8，Type 選 Stretch，Gutter 填 24，Offset 填 32。平板欄位比桌面少，保留主要區塊的縮排空間。
- 手機 Frame 套 4 欄網格：Count 填 4，Type 選 Stretch，Gutter 填 16，Offset 填 20。手機 gutter 與邊界縮小，讓觸控間距與閱讀節奏合理。
- 給關鍵元素設 Constraints：把要響應的元素選起來，在右側 Constraints 面板設定 Left and Right，讓元素貼著欄位左右邊界。沒有這一步，再漂亮的網格也只是背景。
- 把數值寫進設計系統：把 desktop-grid-12、tablet-grid-8、mobile-grid-4 這三組數值命名後存進 Variables 或設計系統文件，團隊任何成員新增 Frame 時直接套用。
- 產出斷點對照表交付開發：把三個斷點的欄數、gutter、max-width、邊界整理成一張表，連同設計稿交給開發，讓兩端用同一組數字。
這七步走完，你手上會有一套三裝置對齊、可重複套用、能直接交付開發的網格。最容易在第 5 步偷懶：很多設計師把網格設得很漂亮，卻漏掉給元素設 Constraints，結果 Frame 一縮放，元素還黏在原座標，網格形同虛設。Constraints 是網格的配套設定，兩者一起才會讓響應式真正動起來。
進階技巧：網格的重疊、嵌套與 baseline 韻律
當基本欄網格熟練之後，三個進階手法能讓排版再上一層：網格重疊、網格嵌套、baseline 韻律網格。這三者對應的是「版面深度」、「元件精度」與「文字節奏」三個維度。
網格重疊，指的是在同一個 Frame 上同時疊加 Column 網格與 Grid 方格網格。Column 負責水平方向的欄位定位，Grid 方格負責像素級的垂直對齊。兩者疊加時，Column 會以顏色較淺的方式顯示，Grid 方格則作為更細的參考層。這種疊法在需要同時處理欄位佈局與圖示對齊的複雜版面特別有用，例如 Dashboard 同時有資料卡片的欄位排列與圖示的 8pt 對齊需求。
網格嵌套，是把網格套用到元件內部的 Frame。外層 Frame 套桌面 12 欄做主版面，內層的卡片元件再套一組較細的網格做內部排列。這對應的是分層排版觀念：外層管大區塊的位置，內層管元件內部的細節。嵌套時要注意內層網格的 gutter 要小於外層，避免視覺節奏打架。嵌套網格與 Auto Layout 可以共存，Auto Layout 處理排列方向與間距，網格處理對齊基準。
baseline 韻律網格，是用 Row 網格建立文字行距的節奏。設定方式是新增 Row 類型網格，Height 填入你的行高基數（例如 8 或 4），Type 選 Align。文字的行高、段落間距、圖片高度都盡量對齊到 baseline 的倍數，整個版面的垂直節奏就會有一致性。baseline 韻律是排版質感的最後一哩路，它讓文字與圖片在垂直方向有共同的呼吸頻率，讀起來更順暢。對行距與文字層次的細節，排版設計與字體行距視覺層次 有更深入的拆解。
| 進階手法 | 解決的問題 | 適用場景 |
|---|---|---|
| 網格重疊 | 同時需要欄位定位與像素級對齊 | Dashboard、複雜資料介面 |
| 網格嵌套 | 元件內部需要獨立的對齊基準 | 卡片、表單、多欄元件 |
| baseline 韻律網格 | 文字與圖片垂直節奏不一致 | 長文頁、內容站、雜誌式版面 |
網格選型決策矩陣：用兩個維度挑出正確的網格
前面分別討論了流體與固定、12 欄與 4 欄、欄網格與方格網格，但實際拿到一個版面需求時，多數人會卡在「到底該選哪一組」。把判斷收斂成一個二維矩陣，能讓選型從憑感覺變成可重現的流程。兩個維度分別是：版面要不要跨裝置響應（橫軸），以及內容要不要結構化對齊（縱軸）。把你的版面丟進這個象限，對應的網格類型幾乎就確定了。
| 象限 | 跨裝置響應 | 結構化對齊 | 建議網格類型 | 典型場景 |
|---|---|---|---|---|
| 第一象限 | 要 | 要 | Column 流體網格（12/8/4 遞減） | Web App、電商、內容站 |
| 第二象限 | 要 | 不需要 | Column 流體網格＋大邊界 Offset | 品牌形象首頁、活動 Landing Page |
| 第三象限 | 不需要 | 要 | Column 固定網格（Align）或 Grid 方格 | 固定尺寸海報、社群圖卡、Banner |
| 第四象限 | 不需要 | 不需要 | Grid 方格網格或不安裝網格 | 插畫、藝術排版、實驗性版面 |
第一象限是網格價值最大的區塊，多數商業專案都落在這裡，必須建立完整的桌面 12、平板 8、手機 4 三組流體網格，並把數值寫進設計系統。第二象限的版面要響應，但內容本身以視覺為主、不強調欄位切分，這時流體網格的重點放在撐住斷點不破圖，Offset 可以放大到 48 甚至 64px，讓留白成為主要的視覺語言。第三象限不需要跨裝置，卻要像素級對齊，這時用 Align 固定網格或 Grid 方格網格，把每個元素鎖在精確座標上，例如社群圖卡常用 1080x1080 的固定 Frame。第四象限兩者都不需要，網格變成可有可無的參考，插畫與藝術排版在這裡可以完全跳脫欄位框架。
這個矩陣的用處在於它把三個原本糾纏在一起的問題拆開：要不要用網格、用哪種網格、要不要流體。先問跨不跨裝置，再問要不要結構化對齊，答案組合直接指向一種網格類型。把這張表貼在設計系統文件裡，新進設計師拿到需求時先過一次矩陣，就能避免把 12 欄流體網格硬套到一張單尺寸海報上，也不會把固定方格拿去做響應式首頁。對版面分類觀念有興趣，可以對照 網頁版面設計與響應式排版觀念 的分類邏輯。
網格開了卻沒效果：5 個常見原因
設了 Layout Grid，排版看起來還是亂、響應式還是破，通常不出五個原因。逐一排查，多半能在半小時內找到癥結。
- 元素沒設 Constraints：網格只開在 Frame，但元素沒設 Constraints，Frame 縮放時元素固定在原座標，網格形同虛設。這是最常見的破圖原因：網格定義了欄位的位置，Constraints 才決定元素要不要跟著欄位流動。
- 用 Align 卻期待流體響應：Align 是固定網格，欄位不會跟著 Frame 伸縮。期待它響應，當然破圖。
- gutter 與開發端對不上：設計設 24px，開發寫 16px，設計與成品之間就會出現位移。這類問題在 Core Web Vitals 與版面穩定度 CLS 上有時還會演變成版面位移。
- 手機平板沿用桌面 12 欄：12 欄塞進 375px 寬的 Frame，每欄窄到放不下內容，欄位形同沒用。
- 把網格當裝飾開了不管：網格開了卻不依欄位對齊，實際排版仍靠肉眼，等於沒開。
多數破圖不是網格沒開，而是用法錯了。把這五點當成檢查表，每次交稿前跑一遍，響應式出錯的機率會大幅下降。對設計系統化的維護有興趣，網頁設計完整指南與 UI 原則 與 網頁設計必備關鍵元素 提供了更完整的檢查框架。若你想系統化累積作品，作品集網站設計指南 能幫你把網格觀念落地到實際專案。
工具面的補強也別忽略：Figma 必裝外掛與效率工具 裡有不少網格相關外掛，配色與字體這些影響排版的變數，則可參考 網頁配色工具與色彩計畫 與 中文字體設計與字型推薦。要從需求端回推版面，設計思考與使用者需求方法 會給你不同的切入點。
網格的價值要到實作階段才會浮現：欄數寫進設計系統、套到實際版面、交給開發，再跟網站速度與圖片載入這些環節串起來，設計稿才會變成可上線、可被搜尋引擎讀懂的成品。版面穩定度與搜尋表現的關聯，從 Google Search Console 安裝 之後才看得到實際資料，把網格規格寫死、交付對齊，正好能在這份報表裡驗收。
破圖診斷流程：從症狀回推到網格設定
前一段列出五個常見原因，但實際拿到一張破圖的設計稿時，要快速定位是哪一個原因造成的，需要一條可依循的診斷路徑。把破圖的症狀分類，再對應到網格的設定層，能在幾分鐘內鎖定問題根源。這條流程把「症狀、檢查點、修正動作」串起來，讓排查從經驗判斷變成可重複執行的步驟。
| 破圖症狀 | 先檢查 | 對應的修正動作 |
|---|---|---|
| 桌面正常、手機元素全擠在一起 | 手機 Frame 是否套 12 欄 | 改套 4 欄流體網格，重排內容 |
| Frame 縮放時元素黏在原座標不動 | 元素有無設 Constraints | 給元素設 Left and Right 或 Scale |
| 設計稿對齊，成品兩側多出留白 | 開發端是否用固定 px 寬度 | 改用 fr 單位或百分比，鎖總寬與邊界 |
| 卡片之間間距忽大忽小 | Gutter 設計值與開發 gap | 兩端統一為同一個 8 的倍數 |
| 主視覺超出 container 邊界 | Offset 與 max-width 是否一致 | 把 max-width 與 padding 寫進同一組變數 |
| 圖片在小螢幕縮到看不清 | 圖片 Constraints 是否設 Scale | 改用容器裁切或設最小寬度 |
這張診斷表的使用方式，是從最左欄的症狀往右對照。先確認手機 Frame 用的是哪一組欄數，這一步就能排除掉大半的行動版破圖；再檢查關鍵元素有沒有設 Constraints，這一步排除掉縮放不跟動的問題；接著比對設計與開發的間距數字，排除掉視覺位移。三個檢查點走完，剩下的多半是 Offset 與 max-width 的邊界對齊問題。把這條路徑記下來，遇到破圖時依序執行，會比逐一嘗試各種設定更有效率。這套從症狀回推設定的思路，與 UI 原型設計與 Wireframe 差異 裡的分層檢查觀念相通。
診斷時還有一個容易誤判的點：有時破圖的根源在 Components 而在主 Frame。Figma 的 Component 有自己獨立的網格與 Constraints 設定，當你在主 Frame 改了網格，Component 內部的元素可能還沿用舊的錨點，結果主版面看起來正常，Component 一放進去就錯位。排查時要把懷疑的 Component 單獨點開，檢查它內部的 Constraints 是否還對應得上新的欄位。這類「主版面對、元件內錯」的破圖，往往要點進去才看得到，是進階排查時最值得多花一分鐘確認的地方。
把這條診斷路徑落到一個典型情境來看，會更具體。以一個內容站或電商網站的情況為例，常見的狀況是設計端把桌面網格設成 Count 12、Gutter 24、Offset 32，並把同一組數字交給開發，但開發端基於既有 CSS 框架習慣，把 gap 直接寫成 16px，container 的 padding 也只留 24px。依典型表現幅度，這類數值落差累積下來，11 條 gutter 合計約差 88px、左右 padding 各少 8px，整組欄位的可用總寬會比設計稿縮減約 6% 到 8%，落在桌面看起來接近正常、但首頁多卡片排版或定價表這類橫向密集版面會明顯往左擠的區間。手機版的問題更尖銳：當桌面 12 欄被原封不動搬進 375px 的 Frame，單欄寬度會掉到約 18 到 22px，連一張縮圖都放不下，這時的修正順序應該是先重套手機專屬的 4 欄網格，再回頭比對兩端的 gap 與 max-width 是否同名同值，繼續在 gutter 上微調通常無濟於事。
這個情境的決策點在於：破圖一旦被定位成數值對不上，修正方向就該回到同一份斷點對照表前面對數字，先統一 gutter 與 padding 這類最容易各自填的值，再檢查 Constraints，重畫網格通常派不上用場。要誠實指出的是，這條路徑的絆腳石多半落在協作而非技術：如果開發端是外包或接手既有專案，他們手上的 CSS 可能沿用舊框架預設值，即使對照表寫得很清楚，實際改動的幅度與排程仍受限於既有程式碼的耦合程度，網格對齊有時得排到下一個重構週期才能真正落地，交件當下未必能驗收完成。這層現實是評估「能不能在這個專案把網格規格收斂」時必須先問清楚的前提。
Dev Mode 與設計 token：把網格變成可交付的程式碼資產
Figma 的 Dev Mode 會把網格資訊顯示在右側面板，開發端可以直接讀到 Count、Gutter、Offset 這些數值，這大幅縮短了設計與開發之間的對數字時間。Dev Mode 雖然方便，仍有它的盲區：它讀的是當下 Frame 的網格設定，如果你把同一個版面用了多組疊加網格，Dev Mode 不一定會把每一層都標清楚；Offset 與 Gutter on outside 這類細節，偶爾也會被開發端忽略。因此把網格數值另寫進設計系統文件或 Variables，仍是不可省的動作，Dev Mode 適合當輔助查驗，卻不該當作唯一依據。
把網格規格化為設計 token，是讓它真正變成程式碼資產的做法。在 Figma Variables 裡，可以為三個斷點各建一組 collection，命名用斷點加欄數（例如 desktop-grid-12、tablet-grid-8、mobile-grid-4），語意清楚也方便搜尋。每組裡存放 count、gutter、offset、max-width 四個變數，足以描述大多數網格規格。這些變數可以套用到任何 Frame 的 Layout Grid 設定，也可以透過 Dev Mode 或 Tokens Studio 這類外掛匯出成 JSON，再由開發端轉成 SCSS 或 Tailwind config 的變數。當設計端的 token 與開發端的變數同名同值，網格規格就從「某個設計師腦裡的數字」升級成兩端共用的單一事實來源。
這套 token 化流程的最大收益，在於把網格變成有版本、可回溯的資產。傳統做法裡，網格規格散落在每個設計師的 Frame 設定與口頭溝通中，改了一次就要逐一通知；token 化之後，所有改動集中在 Variables 面板，套用了該 token 的 Frame 會自動同步，開發端也能看到變更前後的差異。這對多人協作的大型專案尤其關鍵，能避免「設計改了 grid、開發沒跟到」這類隱形落差。把 token 觀念與 SASS SCSS 預處理器加速開發 的變數系統串起來，整個交付鏈就能從設計一路通到程式碼。
什麼情況不該用欄網格：網格的適用邊界
欄網格是強大的工具，卻有明確的適用邊界。把欄網格套用到所有版面，會在某些情境反而綁手綁腳。判斷要不要用欄網格，可以從三個維度檢視：內容是否需要結構化對齊、版面是否跨多個裝置、設計與開發是否需要共用同一組數字。三者都成立，欄網格的價值最大；三者都不成立，欄網格可能變成多餘的框架。
- 純插畫或海報式版面：這類版面追求的是視覺構圖與留白，元素位置由美感決定，欄網格的剛性對齊反而會壓抑創意。這時用 Grid 方格網格做像素級對齊即可，不需要欄結構。
- 單一裝置的固定海報：只在某個固定尺寸輸出、不需要響應的成品（例如活動主視覺、社群圖卡），用 Align 固定網格或單純的參考線就夠了，不需要三裝置的流體網格體系。
- 高度實驗性的藝術排版：刻意打破規則、追求不對稱與衝突感的藝術排版，硬套欄網格會抹平原本想表現的張力。這類版面可以完全不用網格，或只用最寬鬆的 Grid 方格作粗略參考。
- 內容完全流動的單欄長文：純文字的長文頁面，內容本身只有一個流向，欄網格的價值有限。這時用 baseline 韻律網格控制行距，比用欄網格控制水平佈局更有意義。
換句話說，欄網格的核心價值在於「結構化對齊」與「跨裝置響應」這兩件事。當你的版面兩者都不需要，就沒有必要為了用網格而用網格。判斷的工具很簡單：問自己這個版面會不會出現在多個螢幕寬度、設計稿會不會交給開發實作。兩個答案都是肯定，欄網格就是必要的基礎建設；兩個都是否定，可以用更輕量的參考層取代。這個判斷流程能幫你把網格用在刀口上，避免無差別地套用到每一個 Frame。
網格健康度檢查表：交稿前的最後一關
把前面的觀念濃縮成一份可在交稿前逐項打勾的檢查表，能系統性地攔截絕大多數響應式破圖。這份檢查表涵蓋網格本身、Constraints、跨裝置一致性、與開發交付四個面向。
- 桌面 Frame 套 12 欄、平板套 8 欄、手機套 4 欄，三裝置各自有獨立網格。
- 主體版面用 Stretch 流體網格，固定容器區塊才用 Align，沒有混用。
- Gutter 與 Margin 都是 8 的倍數（16、24、32），與間距系統一致。
- 所有需要響應的關鍵元素都設了 Constraints，縮放時會跟著欄位流動。
- Offset 至少留 24 到 32px，內容沒有貼齊 Frame 邊緣。
- 三裝置的網格數值已寫進設計系統文件或 Variables，可被團隊重複套用。
- 附了一張斷點對照表，把欄數、gutter、max-width、邊界一次列清楚給開發。
- 設計端與開發端用同一組數值，沒有設計用流體、開發寫固定 px 的落差。
這八項全部打勾，網格的基礎健康度才算過關。任何一項未過，就回頭對照前面的章節修正。這份檢查表的價值在於把零散的觀念收斂成可執行的流程，讓每一次交稿都跑同一套標準，降低響應式出錯的隨機性。把網格當成有維護成本的基礎建設來對待，團隊的版面一致性才會長期穩定。
常見問題 FAQ
Offset 偏移量什麼時候要用？
要做不對稱版面或內容縮排時用。Offset 負責 Frame 邊界留白，搭配欄位起點控制內容從哪一欄開始佔幾欄，是讓排版有呼吸節奏、避免滿版壓迫的關鍵。
Layout Grid 跟 Auto Layout 有什麼不同？
Layout Grid 定義版面的欄位分佈，Auto Layout 處理單一元件內部的排列與間距，Constraints 則決定元素在 Frame 縮放時怎麼動。三者分工不同，搭配使用不衝突。
沒有設定網格會造成什麼問題？
版面失去一致性，元素各自對齊、邊距憑感覺，響應式縮放時破圖，設計與開發端也無法用同一組數字溝通，後續維護成本大幅上升。
什麼樣的版面不適合用欄網格？
純插畫與海報式版面、單一固定尺寸的輸出、刻意打破規則的藝術排版、純文字單欄長文這幾種情境，欄網格的剛性對齊反而會壓抑表現。判斷標準是版面是否需要結構化對齊與跨裝置響應，兩者都不需要時，用 Grid 方格網格做像素級對齊、或用 baseline 韻律網格控制行距，會比硬套欄網格更合適。
網格跟 baseline 韻律網格要怎麼搭配？
兩者可以疊加在同一個 Frame 上。欄網格用 Column 類型處理水平方向的欄位定位，baseline 韻律網格用 Row 類型建立垂直方向的行距節奏，Height 填行高基數（8 或 4）。文字行高、段落間距、圖片高度盡量對齊到 baseline 的倍數，整個版面就會有水平的欄位一致性與垂直的行距節奏，兩個維度互補。