如何检查响应式设计

一份响应式设计检查清单，应该帮助你判断：用户能否在不同屏幕尺寸下完成任务。一张整齐的移动端截图是有用的证据，但它无法告诉你菜单能否关闭、比较内容是否仍然容易理解，或者提交按钮会不会被弹出的键盘挡住。

先确定任务，再一边执行任务，一边检查布局。对于营销页面，任务可能是理解产品提供什么、比较方案，再找到下一步。对于产品界面，任务可能是找到一条记录、修改其中一个值，然后确认结果。在不同宽度下使用同一项任务，才能看出哪些变化真正有帮助，哪些只是把问题转移到了别处。

先选一张足以暴露问题的页面

选择内容足够丰富的页面，才能让评审有实际意义。几乎空白的落地页可能轻松通过检查，价格页却仍然有问题。选一张包含导航、较长标题、图片、重复内容，以及至少一个重要操作的页面。如果网站包含表单或数据表格，也要把包含这些模式的页面纳入检查。

检查之前，先换掉那些过于容易排版的示例内容。标题只有“团队”的卡片，不太可能暴露出与“区域运营与客户支持”相同的问题。使用真实可信的描述、正常情况下最长的导航标签，以及主体明显靠近某一侧边缘的图片。这些是测试输入，目的是发现真实问题，而不是用荒谬内容故意把页面弄坏。

写清楚哪些事情必须始终能够完成。以虚构的工作坊预约页为例，访客应能读到日期、了解地点、比较场次，并开始预约。如果窄屏布局为了节省空间隐藏了地点，即使画面看起来更干净，也已经丢失了完成任务所需的信息。

先设检查宽度，再检查它们之间的变化

桌面、平板和手机预览，是实用的检查起点，但并不能覆盖页面会遇到的全部情况。可以调整大小的浏览器窗口、分屏使用的平板，或经过缩放的页面，都可能让布局落在设备预设没有覆盖的宽度上。

选择一个窄屏、一个中等宽度和一个宽屏作为检查点。具体数字不是最重要的，重要的是覆盖与你的用户有关的使用条件。初次检查时，可以从大约 360、768 和 1440 CSS 像素开始，再逐渐调整窗口，检查这些宽度之间的布局。

尤其要留意结构发生切换前后的区域。页头在宽屏检查点可能很宽松，在窄屏也能正确折叠，却在即将切换前变得拥挤。三列内容区在某个中间宽度，可能需要比父容器实际分配的更多空间。问题经常出现在到达断点之前，而不是断点本身。

web.dev 的响应式设计指南建议根据内容需求决定何时改变布局，而不是围绕设备名称设定变化。应用这一原则时，记录组件首次无法舒适使用的宽度。这样既能说明为什么需要调整，也能为修复后的复测提供一个明确位置。

一个值得参考的例子：GOV.UK 保留了完整的阅读任务

GOV.UK 布局指南以小屏单列布局为起点，并建议许多宽屏页面采用占三分之二宽度的阅读栏。其官方的三分之二与三分之一分栏示例，展示了同一份内容在空间变窄时如何改为竖向排列。

值得借鉴的是内容之间的关系，而不只是分栏比例：主要解释仍然先出现，辅助资料随后出现。对于你自己的页面，付款前必须了解的法律条件，不会仅仅因为放进侧栏很好看，就变成次要内容。在套用一种降低其优先级的布局之前，先确定这段内容的作用。

这样就能提出一个比“这些列会堆叠”更具体的检查问题。从辅助栏选一句话，找出它限定的是哪个操作。堆叠之后，读者会不会还没看到这句话，就先遇到了那个操作？如果会，响应式实现可能在几何布局上正确，在内容编排上却不正确。应让限定条件随操作一起移动，或明确说明两者的依赖关系。

另一个有用的测试，是用键盘沿着页面操作。视觉排列变了，源代码顺序却可能没有变化。如果画面看起来把控件放在解释之后，键盘焦点却在解释之前就到了控件，评审就需要同时收集布局和阅读顺序的证据。仅凭截图无法解决两者之间的矛盾。

围绕任务检查响应式设计

可以用下面这些检查项作为初始记录，再删去页面中不存在的项目。评审之前就写出预期结果，否则看到缺陷以后，很容易替它找理由。下面的例子是测试条件，并不是所有页面都应采用的统一断点设置。

不要把这些观察合并成一个通过率。装饰性图注被裁掉，与付款操作无法触达，并不是同等严重的失败。先修复阻止用户完成任务的问题，再处理信息错误或缺失，最后改善阅读舒适度和视觉细节。这样的顺序能帮助小团队做出可执行的发布判断，同时不会把尚不完整的评审当成支持所有设备的证明。

在使用过程中逐步检查页面

导航：打开、选择、关闭，再打开

打开每一个会随布局变化的导航控件。菜单图标可能对齐得很漂亮，展开的面板却根本无法使用。检查展开状态，选择一个目标，关闭面板，再重新打开。如果页面有嵌套导航，就继续测试更深一层的项目，不要只停留在第一级。

在工作坊示例中，宽屏页头可能显示“场次”“讲者”“场地”和“预约名额”。窄屏版本可能把前三个链接移入面板。检查“场地”是否仍然存在、标签能否读清，以及关闭面板后访客能否正常回到页面，而不会被残留的透明遮罩挡住。

注意菜单与屏幕其他部分之间的关系。很高的面板可能需要独立滚动，也可能需要允许底层页面滚动。不论选择哪种方式，访客都应该能够到达最后一个菜单项和关闭控件。如果面板只有在视口足够高时才能用，那它仍然存在响应式问题。

再用键盘重复同一任务。此时要确认布局变化是否让某个控件无法继续操作，或把当前焦点隐藏了。记录触发问题的确切操作顺序，修复时才能有针对性地处理。

阅读顺序：按照移动端的顺序读下去

多列变成单列堆叠时，值得重新评审阅读顺序。桌面版本可能依靠某些空间关系来传达信息，而这些关系在移动端已经不存在了。原本与解释并排的价格，可能与解释相隔好几屏；一段图注也可能看起来像在描述下一张图片，而不是上一张。

不要对照桌面布局，直接沿着窄屏页面从上往下读。思考每个部分为读者接下来理解什么做了准备。在预约页中，用户应先看到场次详情，再被要求选择场次。如果在选择操作和解释之间插入一张大型装饰图片，操作与说明就可能显得脱节。

留意桌面端左右交替排列的内容区。先是左图右文，接着右图左文，如果实现时只是按源元素顺序堆叠，移动端的顺序就可能前后不一致。先决定每张图片的作用是引出文字，还是在文字之后举例说明；对于承担相同作用的内容，应让这种关系保持一致。

溢出：先找出原因，再决定如何处理

滚动查看整张页面，寻找超出容器边界的内容。常见线索包括被截断的按钮标签、伸出屏幕的卡片边缘，以及把旁边内容挤乱的页脚链接。遮罩层和展开内容也要检查；页面静止时可能放得下，打开控件后却未必。

区分意外溢出和有意设计的滚动区域。 较宽的比较表在自己的区域里横向滚动，可能是合理的；一张过大的插图导致整个页面左右移动，则是另一种问题。如果横向滚动是有意设计的，就需要让访客能发现还有更多内容，并且在滚动时知道自己正在读什么。

不要以为加上一条全局隐藏溢出的规则，就完成了修复。它可能让页面外缘看起来干净，却把原本引发问题的内容直接裁掉。先找出具体元素，再判断需要改变的是宽度、换行方式、位置，还是容器。修改之后，还要确认有用的内容并没有就这样消失。

以工作坊页面为例，假设票券卡片里的场地名称很长。有帮助的修复可能是允许名称换行，并让卡片随之增高。缩小卡片内所有文字也能让它放得下，但这会牺牲其他信息的可读性，而那些信息本来并没有造成问题。

检查每种裁切下，图片是否仍能传达原意

图片在技术上没有超出容器，也不代表它能有效传达信息。观察图片形状改变以后，还保留了什么。如果图片用来展示入口，入口就应仍然可见。如果用来解释某项功能，相关界面区域就不应小到无法辨认。

对于编辑配图中的照片，或许可以改变裁切方式，同时保留主体；但对于教学截图，裁掉标签可能就把解释一并删掉了。这两类素材需要做不同决定。在选择更紧的裁切、换一张素材，或为图片提供更大的独立展示区域之前，先回顾它的用途。

用周围的文字检验图片。如果句子写着“选择高亮显示的场次”，但图片按实际尺寸显示时根本看不见高亮，这张图就不再支持那句话了。此时，相关控件的局部特写，可能比缩小到适应容器的完整屏幕截图更有用。

检查实际交付到页面上的图片，不要只看源文件尺寸。高分辨率文件如果显示得太小，同样可能无法阅读；尺寸本来合适的图片，如果加载了错误的版本，也可能发虚。记录你观察到的是哪一种情况。这一区别能帮助实施修复的人判断，应该调整布局还是更换图片资源。

保持决策信息与操作控件的关联

响应式布局应保留信息与其所支持操作之间的联系。在价格区，这意味着方案名称、相关限制、价格和按钮，仍然能被识别为同一个选项。在预约表单中，这意味着访客走到最后的确认操作时，仍能清楚知道自己选中了哪个场次。

仔细检查重复出现的按钮。如果所属卡片在视觉上被拆散，三个同样写着“继续”的按钮就容易混淆。你可能需要加强分组、让方案标签更明确，或让操作文字更具体。优先选择能恢复关联、对原设计改动最小的办法，不必给每一项都加上厚重的装饰。

检查标签换行时的控件。如果内边距、对齐和相邻控件的关系仍然协调，两行文字的按钮也可以接受。关键是用户是否仍能分清操作，并舒适地触发它。相比按钮稍微变高，标签只剩第一个词、后面全被截断，是更严重的问题。

把吸附或固定的元素也纳入检查。固定预约栏可以让主要操作始终可见，但也可能遮住价格说明或最后一个表单字段。滚动到底部、打开可展开的内容，并让某个字段获得焦点。这个元素在这些状态下也必须值得占据那块空间，而不只是开场截图里看起来漂亮。

在表单状态发生变化后继续测试

表单值得单独检查一遍，因为交互会改变内容量。错误信息、已选选项或确认提示都可能增加高度，改变字段之间的关系。要使用真实可信的输入，并至少触发一次可以修正的错误来检查表单，而不只是查看一排空输入框。

在窄屏上，如果条件允许，就在真实设备中调出屏幕键盘。检查当前字段是否仍然可见，以及能否到达下一步操作。桌面预览有助于检查布局，但仅靠它无法确认每一种移动浏览器会如何处理键盘和视口。

对正常情况下允许较长内容的字段，输入一个更长的值。完整组织名称、由多个部分组成的姓氏，或较长的电子邮箱地址，都可能暴露出短示例没有发现的截断问题。视觉评审的目的不是改变应用的校验规则，而是确保应用接受的输入在界面中仍然能够看懂。

出现错误后，确认页面仍然清楚说明需要修正什么。不能因为其他部分移动了位置，就让错误信息与对应字段分开。如果表单使用错误摘要，也要检查摘要与各字段之间的关联。记录问题属于布局、措辞、焦点行为，还是实际校验逻辑，方便交给合适的负责人处理。

区分布局放不下与内容本身的问题

有些看似响应式失效的问题，根源是内容不清楚，而不是空间不足。重复标题的段落，可能让移动端页面无谓地变长；一排六个操作，可能意味着操作优先级尚未理清。在压缩设计之前，先问问这些内容是否有明确作用。

另一些问题则确实属于布局。不能因为当前组件太僵硬，就删掉重要条款。预约页上的取消条件，即使让构图更复杂，也可能是必要信息。根据访客何时需要它，正确做法可能是换个更好的位置、使用可展开的解释，或提供更多竖向空间。

一个有用的判断方法是：这条信息是否应该在所有宽度下都可获取？如果是，就应调整呈现方式。如果信息是否相关，确实取决于当前任务或状态，那么条件显示可能合适。对于在所有设备上都支持同一个决策的信息，仅凭宽度就将其移除，理由并不充分。

MDN 的响应式设计概述把响应式视为弹性布局、媒体、排版和视口行为的结合。这有助于分配修复工作：一个小屏问题，并不意味着整张页面都需要重新生成。

把观察转化为小而可验证的修改

每条问题只聚焦一个具体故障，写清组件、触发条件和预期行为。例如：“在中等预览宽度下，‘场地’与‘预约名额’发生重叠。请在两者碰到一起之前折叠页头，同时保留标签和预约目标页面。”这样的修改请求，比“把平板布局做好一点”更有帮助。

如果你在 OpenDesign 中工作，可以先用桌面、平板和手机预览进行初步比较。通过评论或聊天提交观察结果，再检查更新后的 HTML。当需要的变化很具体时，也可以手动编辑支持修改的文字、链接、图片和样式。

对于结构性修改，要明确哪些内容应保持不变。如果页头需要换一种布局，就在这次修改中保留原有内容和链接目标。如果图片需要更合适的裁切，就避免同时改动周围文案。让这些变量保持稳定，更容易判断本次变化是否解决了记录中的问题。

先复测原来失败的条件，再检查相邻宽度和相关状态。让菜单在一个宽度下放得下的修复，可能会让另一个宽度下的页头无谓地拥挤。按钮增高后，也可能暴露出卡片高度被固定的问题。这一轮简短回归是原修复的一部分，而不是可做可不做的额外润色。

留下一份别人能接着使用的评审记录

在宣布响应式评审完成之前，要在每一个检查点，从头到尾重复主要任务：阅读内容、打开控件，直到得到结果。然后，至少再检查一个位于检查点之间、布局会发生变化的宽度。保存重要展开状态的证据，而不只是三张好看的静止页面截图。

最终记录可以很简短：检查了哪些页面，使用了哪些宽度和浏览器，哪些任务成功完成，还有哪些条件没有测试。如果无法使用真实移动设备，就明确说明。如果表格横向滚动是有意设计的，也要记录这个决定，避免下一位评审者把它当成遗漏的缺陷。

根据问题会妨碍什么，给尚未解决的问题排优先级。操作被隐藏，或必要条件无法阅读，都可能让任务无法完成。标题不够顺眼但仍能看懂，通常优先级较低。这样能为下一轮修改确定合理顺序，也不会否认视觉质量的重要性；只是避免让细节润色掩盖了那些阻止用户使用页面的问题。