UI走查中95%的问题源于“间距不准”，而肉眼难以量化，导致沟通低效。DevTools（浏览器开发者工具）作为设计师与前端的“共同尺子”，能将页面视觉问题转化为可测量、可验证的技术事实。本文从设计师视角系统讲解如何用DevTools高效走查，希望可以帮到大家。
如果你经常参与 UI 走查，应该会有类似的体验：设计稿里一切工整、呼吸感刚刚好，到了线上页面，总有种说不出的别扭——按钮看起来有点胖，列表挤成一团，弹层莫名“顶头”——你明明感觉哪里不对，却很难说清楚问题到底在哪儿。
有一组数据挺扎心：在一次前端对UI 走查问题的统计中，“间距”占到了 95%、字体相关只有 3%、边框背景色等合计只有 2%。
换句话说，大部分“看着不舒服”，其实都跟间距有关系。但是间距很难通过肉眼直接量化，导致设计师走查费时、与前端沟通效率低，前端修改有时也是“跟着感觉来”、难以达到最优效果。
这也是为什么，我把 DevTools（开发者工具）当成 UI 走查的标配工具。
这篇文章，就想从一个设计师的视角，讲讲什么是 DevTools 、如何用 DevTools 做高效的 UI 走查，把实践中总结出的那一整套方法，汇成一条实际好操作的路径。
本文不涉及复杂的代码和技术概念，放心享用。
DevTools（Developer Tools，开发者工具）是现代浏览器自带的一套网页检查与调试工具，用于查看网页的结构、样式、脚本、网络请求和性能等信息。它能够实时展示页面背后的代码和布局，并允许用户在本地修改样式、观察变化。
DevTools 不是独立软件，而是浏览器内置功能。目前主流浏览器都提供了自己的 DevTools，包括Chrome、Safari、Firefox、Edge等。
DevTools 不是只给前端用的“黑客面板”，而是设计师与工程师之间的一把“共同的尺子”，它能让一个页面的“表面外观”变成“透明结构”：你可以在上面看到每一个元素的真实尺寸、间距、颜色和字体，可以在几秒钟内验证“到底是谁没对齐”，也可以通过临时修改样式，把你脑子里的改善方案可视化地呈现出来。
换句话说，它提供了一种把 UI 视觉现象与技术实现逻辑直接对应起来的能力。
开始之前，第一步永远是把 DevTools 打开。最常用的方式是：
很多设计师第一次看到 Elements 面板时，会被大片的 <div> 吓到。
其实可以把它当作“页面骨架实时展开图”：每一层缩进就是嵌套关系，每个标签对应页面上的一个区域。
我们不需要懂它，只需要关注与UI走查密切相关的三个面板：样式Styles（样式规则）、计算样式Computed（最终计算值）、布局Layout（布局体系）。
如果你对英文属性名不够熟，可以在右上角齿轮按钮里，把语言切换到中文，这能降低学习成本。
要做 UI 走查，第一件事就是精准选中目标元素，常见方式包括：
点击 DevTools 左上角的小箭头
在页面上移动鼠标，高亮所选区域，点击可锁定元素
适合复杂、多层嵌套的界面。
hover到具体元素，右键 → 检查（Inspect）适合按钮、标题、图标等肉眼识别明显的元素
既然 UI 走查里 95% 的问题都是”间距看着不对”，学会量间距是最划算的一件事。
有两个方法：
要理解间距，首先要认识 Box Model（盒模型）——这是网页布局的基础概念，它将每个元素看作一个”盒子”，由内到外分为四层：content（内容区）、padding（内边距）、border（边框）、margin（外边距）。
DevTools 能将这个模型可视化展示，让你清楚看到每一层的数值，从而与设计稿进行比对，精准定位间距问题的根源。
在页面或者元素Elements 面板中移动鼠标，页面对应区域会出现不同颜色的高亮框：橙色：margin、绿色：padding。
适合快速巡检整体布局。
至于颜色、字体、行高等样式，可以从样式Style或者计算样式Computed查看。
Style面板显示了所有作用于当前元素的样式规则，包括颜色、字号、字重、字体、边框、阴影、圆角。
如果你发现同一个属性，比如font-size，出现了很多次，有的还被划上了删除线。也别奇怪，这代表有多个规则作用于它。
怎么找到哪个是真实的值呢？有两个方法：
一是Styles 面板里的规则，是按从上到下的优先级排列：越靠上的规则优先级越高。我们只需要从上往下找即可。被覆盖的会被划上删除线，不再生效，直接忽略就行。
二是计算样式Computed面板。
它显示了元素最终的样式，更直观，更适合回答：最终字号是多少？行高值是多少？是否有透明度？宽高是多少？
并且可以勾选“组合”，将这些属性分组显示，分为Layout、Text、Appearance和Other。更易查找。
DevTools 最强大的地方在于：你不仅能看到样式，还能立即修改它，实时预览效果——这让走查从”发现问题”变成了”提出方案”。
在 样式Styles面板中，找到你想修改的属性（比如 font-size: 14px），直接点击数值部分，就能进入编辑状态。
步骤：点击数值（如 14px） → 输入新值（如 16px） → 按 Enter 确认，页面立即生效
适合快速微调单个属性。
选中数值后，无需手动输入，可以用键盘上下键进行微调：
适合精细调整间距、透明度等需要”试着来”的场景。
如果某个属性根本不存在（比如你想加个 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）。
如果点击网格名称（或勾选复选框，或直接在元素Style面板中点击对应的 Grid 标签，三者是联动的），页面中会直接高亮显示网格区域，你可以看到：网格线与区域划分、网格线行号与列号、轨迹大小、区域名称、延长网格线（用于检查模块对齐效果）。
这对于排查”为什么这个卡片没对齐”特别有用。
如果点击弹性盒子名称（或勾选，或直接在元素中点击对应的 Flex 标签，三者是联动的），页面中会高亮显示色块、框线，你可以看到：主轴方向（横向还是纵向）、子项的分布方式（居中、两端对齐等）、容器与子项的边界、哪个元素占用了过多空间。
你还可以：点击色块，修改框线颜色、点击定位图标，直接跳转到 样式 Styles 中的对应代码。
这对于排查”为什么按钮挤在一起”或”为什么间距不均匀”非常有帮助。
DevTools 的“设备模拟”工具，让响应式问题无处可藏。
观察：导航是否撑开、文字是否过密、元素是否溢出、弹窗是否遮挡、按钮是否掉到底部……
并支持：切换设备型号、改变屏幕宽度、翻转屏幕方向。
当你熟练掌握了 DevTools 的基础操作，你会发现自己开始好奇更深的问题：这些元素是怎么组织的？移动端怎么走查?能不能让 AI 帮我自动找问题？
这些问题没有标准答案，但值得探索。
移动端页面分两种：H5 网页和原生 UI。它们的走查方式完全不同。
如果是 App 内的 H5 页面（WebView），你可以通过真机调试，直接用 DevTools 查看。如果是原生 UI（比如 iOS 的 UIKit、SwiftUI），DevTools 就无能为力了，需要用专门的工具，比如 Lookin。
怎么判断一个页面是不是原生？
有几个简单的特征：文本无法长按选中、滑动非常顺滑、动画丝滑、左右滑返回手势明显（iOS）。如果”像网页但又不像网页”，那可能是混合页面——Native 外框 + 内嵌 H5。
有团队已经在尝试用 AI 做自动化 UI 走查，比如让 AI 批量识别间距、颜色、字号等问题。
但目前来看，AI 更适合做”初筛”——它能快速找出明显的偏差，但最终的判断和决策，还是需要人来做。因为很多设计问题不是”对错”，而是”合不合适”。
未来，走查可能会变成这样：AI 先跑一遍，标出疑似问题；设计师再用 DevTools 逐一确认，给出具体的修改建议。这样既提高了效率，又保留了人的判断力。
当你习惯了这种基于 DevTools 的走查方式，你会发现自己跟以前有一处很大的不同：过去你走查，是在“凭感觉找问题”，现在你走查，是在“用证据找原因”。
DevTools 不是让你变成前端工程师，而是让你能够理解界面背后的结构、逻辑和约束，并提供既符合体验、又便于实现的解决方案。
最终，UI 走查也会从一场“找谁背锅”的会，变成一场“让产品更好”的会——设计师和工程师坐在同一个 DevTools 界面前，说着同一种语言，指着同一份证据。而这，正是一个成熟团队应该拥有的样子。
作者：韩筱婷
本文由人人都是产品经理作者【58UXD】，微信公众号：【58UXD】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。