如果你經常參與 UI 走查，應該會有類似的體驗：設計稿里一切工整、呼吸感剛剛好，到了線上頁面，總有種說不出的別扭——按鈕看起來有點胖，列表擠成一團，彈層莫名“頂頭”——你明明感覺哪里不對，卻很難說清楚問題到底在哪兒。
有一組數據挺扎心：在一次前端對UI 走查問題的統計中，“間距”占到了 95%、字體相關只有 3%、邊框背景色等合計只有 2%。
換句話說，大部分“看著不舒服”，其實都跟間距有關系。但是間距很難通過肉眼直接量化，導致設計師走查費時、與前端溝通效率低，前端修改有時也是“跟著感覺來”、難以達到最優效果。
這也是為什么，我把 DevTools（開發者工具）當成 UI 走查的標配工具。
這篇文章，就想從一個設計師的視角，講講什么是 DevTools 、如何用 DevTools 做高效的 UI 走查，把實踐中總結出的那一整套方法，匯成一條實際好操作的路徑。
本文不涉及復雜的代碼和技術概念，放心享用。
更多相關干貨：
DevTools（Developer Tools，開發者工具）是現代瀏覽器自帶的一套網頁檢查與調試工具，用于查看網頁的結構、樣式、腳本、網絡請求和性能等信息。它能夠實時展示頁面背后的代碼和布局，并允許用戶在本地修改樣式、觀察變化。
DevTools 不是獨立軟件，而是瀏覽器內置功能。目前主流瀏覽器都提供了自己的 DevTools，包括Chrome、Safari、Firefox、Edge等。
DevTools 不是只給前端用的“黑客面板”，而是設計師與工程師之間的一把“共同的尺子”，它能讓一個頁面的“表面外觀”變成“透明結構”：你可以在上面看到每一個元素的真實尺寸、間距、顏色和字體，可以在幾秒鐘內驗證“到底是誰沒對齊”，也可以通過臨時修改樣式，把你腦子里的改善方案可視化地呈現出來。換句話說，它提供了一種把 UI 視覺現象與技術實現邏輯直接對應起來的能力。
開始之前，第一步永遠是把 DevTools 打開。最常用的方式是：
- 鍵盤黨可以用 Command + Option + I或 F12
- 鼠標黨可以直接在頁面上右鍵 →「檢查（Inspect）」
很多設計師第一次看到 Elements 面板時，會被大片的 <div> 嚇到。
其實可以把它當作“頁面骨架實時展開圖”：每一層縮進就是嵌套關系，每個標簽對應頁面上的一個區域。
我們不需要懂它，只需要關注與UI走查密切相關的三個面板：樣式Styles（樣式規則）、計算樣式Computed（最終計算值）、布局Layout（布局體系）。
如果你對英文屬性名不夠熟，可以在右上角齒輪按鈕里，把語言切換到中文，這能降低學習成本。
要做 UI 走查，第一件事就是精準選中目標元素，常見方式包括：
方法一：用“選取器”在頁面上點選
- 點擊 DevTools 左上角的小箭頭
- 在頁面上移動鼠標，高亮所選區域，點擊可鎖定元素
適合復雜、多層嵌套的界面。
方法二：右鍵檢查
hover到具體元素，右鍵 → 檢查（Inspect）
適合按鈕、標題、圖標等肉眼識別明顯的元素
既然 UI 走查里 95% 的問題都是"間距看著不對"，學會量間距是最劃算的一件事。有兩個方法：
方法一：看 Box Model
要理解間距，首先要認識 Box Model（盒模型）——這是網頁布局的基礎概念，它將每個元素看作一個"盒子"，由內到外分為四層：content（內容區）、padding（內邊距）、border（邊框）、margin（外邊距）。
DevTools 能將這個模型可視化展示，讓你清楚看到每一層的數值，從而與設計稿進行比對，精準定位間距問題的根源。
方法二：hover 實時高亮
在頁面或者元素Elements 面板中移動鼠標，頁面對應區域會出現不同顏色的高亮框：橙色：margin、綠色：padding。
適合快速巡檢整體布局。
至于顏色、字體、行高等樣式，可以從樣式Style或者計算樣式Computed查看。
視角一：樣式Styles（全部規則）
Style面板顯示了所有作用于當前元素的樣式規則，包括顏色、字號、字重、字體、邊框、陰影、圓角。
如果你發現同一個屬性，比如font-size，出現了很多次，有的還被劃上了刪除線。也別奇怪，這代表有多個規則作用于它。
怎么找到哪個是真實的值呢？有兩個方法：
一是Styles 面板里的規則，是按從上到下的優先級排列：越靠上的規則優先級越高。我們只需要從上往下找即可。被覆蓋的會被劃上刪除線，不再生效，直接忽略就行。
常見的CSS屬性字段名，我已放在文末，需要可自取。
視角二：Computed（最終值）
二是計算樣式Computed面板。
它顯示了元素最終的樣式，更直觀，更適合回答：最終字號是多少？行高值是多少？是否有透明度？寬高是多少？
并且可以勾選“組合”，將這些屬性分組顯示，分為Layout、Text、Appearance和Other。更易查找。
DevTools 最強大的地方在于：你不僅能看到樣式，還能立即修改它，實時預覽效果——這讓走查從"發現問題"變成了"提出方案"。
修改方式一：直接點擊數值
在 樣式Styles面板中，找到你想修改的屬性（比如 font-size: 14px），直接點擊數值部分，就能進入編輯狀態。
步驟：點擊數值（如 14px） → 輸入新值（如 16px） → 按 Enter 確認，頁面立即生效
適合快速微調單個屬性。
修改方式二：上下鍵微調
選中數值后，無需手動輸入，可以用鍵盤上下鍵進行微調：
- ↑ / ↓：每次增減
- 1Shift + ↑ / ↓：每次增減 10
- Option + ↑ / ↓（Mac）或 Alt + ↑ / ↓（Windows）：每次增減 0.1
適合精細調整間距、透明度等需要"試著來"的場景。
修改方式三：添加新屬性
如果某個屬性根本不存在（比如你想加個 border-radius），可以在 Styles 面板的任意規則塊內：
點擊空白處?→ 輸入屬性名（如 border-radius）→?輸入值（如 8px）?→?按 Enter 確認
頁面立即應用新樣式。
修改方式四：臨時禁用某條樣式
有時你不確定是哪條規則導致了問題，可以用"復選框"快速開關樣式：
在 Styles 面板中，每條樣式左側都有一個復選框，取消勾選即可臨時禁用該規則，觀察頁面變化。
適合排查"到底是哪條規則在搗亂"。
修改方式五：復制修改后的樣式值
當你調整出滿意的效果后，可以：
右鍵點擊修改后的屬性?→ 選擇"復制" → "復制聲明"或"復制規則"?→?粘貼到文檔或發給前端
這樣你就能把"視覺方案"轉化為"技術語言"，大幅提升溝通效率。
注意：所有修改都是臨時的，刷新頁面后會恢復原樣。DevTools 不會改動源代碼，只是讓你在本地預覽效果。
許多 UI 缺陷只在 hover、active、focus 狀態下暴露，例如：hover 時顏色未變化、點擊態幾乎無反饋、表單 focus 出現丑陋藍框。
在 Styles 面板頂部點擊 :hov，勾選對應狀態即可模擬：hover、active、focus、visited......無需鼠標繁瑣操作。
當你發現"每個元素單獨看都沒問題，但整體就是不順眼"時，問題往往出在布局層級。
這時候，DevTools 的布局 Layout 面板就能派上用場——它能把頁面背后隱藏的布局邏輯全部"照亮"。
點擊右側面板中的布局 Layout，會顯示所有網格布局（Grid）和彈性盒子布局（Flexbox）。
Grid 網格布局視角
如果點擊網格名稱（或勾選復選框，或直接在元素Style面板中點擊對應的 Grid 標簽，三者是聯動的），頁面中會直接高亮顯示網格區域，你可以看到：網格線與區域劃分、網格線行號與列號、軌跡大小、區域名稱、延長網格線（用于檢查模塊對齊效果）。
這對于排查"為什么這個卡片沒對齊"特別有用。
Flexbox 彈性盒子布局視角
如果點擊彈性盒子名稱（或勾選，或直接在元素中點擊對應的 Flex 標簽，三者是聯動的），頁面中會高亮顯示色塊、框線，你可以看到：主軸方向（橫向還是縱向）、子項的分布方式（居中、兩端對齊等）、容器與子項的邊界、哪個元素占用了過多空間。
你還可以：點擊色塊，修改框線顏色、點擊定位圖標，直接跳轉到 樣式 Styles 中的對應代碼。
這對于排查"為什么按鈕擠在一起"或"為什么間距不均勻"非常有幫助。
DevTools 的“設備模擬”工具，讓響應式問題無處可藏。
觀察：導航是否撐開、文字是否過密、元素是否溢出、彈窗是否遮擋、按鈕是否掉到底部......
并支持：切換設備型號、改變屏幕寬度、翻轉屏幕方向。
當你熟練掌握了 DevTools 的基礎操作，你會發現自己開始好奇更深的問題：這些元素是怎么組織的？移動端怎么走查?能不能讓 AI 幫我自動找問題？
這些問題沒有標準答案，但值得探索。
移動端走查：H5 能用 DevTools，原生要用專門工具
移動端頁面分兩種：H5 網頁和原生 UI。它們的走查方式完全不同。
如果是 App 內的?H5 頁面（WebView），你可以通過真機調試，直接用 DevTools 查看。如果是原生 UI（比如 iOS 的 UIKit、SwiftUI），DevTools 就無能為力了，需要用專門的工具，比如 Lookin。
怎么判斷一個頁面是不是原生？
有幾個簡單的特征：文本無法長按選中、滑動非常順滑、動畫絲滑、左右滑返回手勢明顯（iOS）。如果"像網頁但又不像網頁"，那可能是混合頁面——Native 外框 + 內嵌 H5。
AI 自動化走查：人機協作，而非完全替代
有團隊已經在嘗試用 AI 做自動化 UI 走查，比如讓 AI 批量識別間距、顏色、字號等問題。
但目前來看，AI 更適合做"初篩"——它能快速找出明顯的偏差，但最終的判斷和決策，還是需要人來做。因為很多設計問題不是"對錯"，而是"合不合適"。
未來，走查可能會變成這樣：AI 先跑一遍，標出疑似問題；設計師再用 DevTools 逐一確認，給出具體的修改建議。這樣既提高了效率，又保留了人的判斷力。
當你習慣了這種基于 DevTools 的走查方式，你會發現自己跟以前有一處很大的不同：過去你走查，是在“憑感覺找問題”，現在你走查，是在“用證據找原因”。
DevTools 不是讓你變成前端工程師，而是讓你能夠理解界面背后的結構、邏輯和約束，并提供既符合體驗、又便于實現的解決方案。
最終，UI 走查也會從一場“找誰背鍋”的會，變成一場“讓產品更好”的會——設計師和工程師坐在同一個 DevTools 界面前，說著同一種語言，指著同一份證據。而這，正是一個成熟團隊應該擁有的樣子。
復制本文鏈接 文章為作者獨立觀點不代表優設網立場，未經允許不得轉載。
熱評 冬音澗