我最近检查一个目录页时，桌面上的第一印象其实不错：多列内容排得整齐，标题区域也没有明显错位，筛选和分页都在原来的位置。可是把视口切到手机宽度，问题很快就露出来了。首屏看不到目录，长标题被截断，用户甚至还没开始浏览，就已经不知道页面接下来要做什么。
当时我一开始以为这是一个典型的响应式问题，可能只要把列数减少、把间距压小，再补几条媒体查询就够了。后来继续检查才发现，真正的问题不是桌面布局缩小得不够彻底，而是页面把桌面用户的阅读顺序，原封不动地带到了手机上。目录、标题、筛选、加载状态和链接定位，都默认用户有足够的屏幕和耐心。
手机适配的起点不是把桌面页面压窄，而是先回答首屏必须帮助用户完成什么。
首屏先解决一个任务
在桌面上，多个区域可以同时出现，用户能够一眼扫过目录、标题和辅助信息。手机则不同。屏幕一次只能容纳有限内容，任何一个放错位置的模块，都会把真正重要的动作推到首屏之外。于是我没有先改宽度，而是先给首屏写出一个任务：让用户看到内容目录，并能判断下一步应该打开哪一项。
这个任务看起来简单，却改变了后续判断。目录不是装饰，也不是桌面版里“顺便放在侧边”的辅助栏；在手机上，它是用户确认页面方向的入口。标题也不能只追求一行显示，因为标题承担的是识别内容的作用。为了保持一行而截断，反而会让用户无法区分相近项目。
如果不先定义首屏任务，后面的适配很容易变成局部修补：这里少留一点空白，那里把字号调小，再把一个模块藏进折叠菜单。页面或许不再溢出，但用户仍然要猜目录在哪里、当前看到的是什么，以及下一步该点哪里。
我选择把目录前置，并允许长标题完整换行，是因为这两项修改直接服务于首屏任务。它们不一定让页面看起来最紧凑，却让用户更快获得方向感。手机上的空间有限，真正应该压缩的是装饰和次要信息，不是识别内容所需的信息。
换行不是排版小事
长标题被截断时，表面上只是一个 CSS 细节，实际上会影响整个浏览流程。用户点开一个看不完整的标题，可能先要返回，再换另一个项目，或者误以为页面没有自己要找的内容。对于目录页来说，标题不是一段可以随意省略的文字，而是用户做选择时依赖的线索。
我因此把“能不能一行放下”换成了“在有限宽度下能不能辨认”。标题允许完整换行后，单个条目的高度会增加，页面也不如桌面版紧凑，但这个代价是明确且可接受的。比起让用户在截断内容中猜测，增加一点垂直滚动更诚实。
这里最容易误判的是把横向滚动条当成唯一的响应式指标。确实，3种宽度下都没有横向溢出，是一个必要结果；但没有滚动条不代表信息顺序正确，也不代表文字可读。一个页面可以在技术上完全塞进屏幕，却把关键目录藏在很下面，或者把每个标题裁成无法判断的半句话。
因此我把验收拆成了两层：先看内容是否按任务顺序出现，再看尺寸、间距和溢出是否稳定。次要文字的对比度实测达到6.13:1，在线状态文字达到6.90:1，这些数字说明视觉层面的可读性有了证据，但它们不能替代对信息顺序的检查。
筛选要能回到起点
桌面页面上的筛选控件通常比较宽，用户可以同时看到条件、结果和分页。到了手机上，筛选动作更容易把用户带进一个局部状态：结果被过滤了，分页位置变化了，原来的目录位置也可能不再对应。这个时候，清空筛选不是附加功能，而是让用户重新获得方向的恢复入口。
我补上清空筛选，并把它和分页、目录定位放在同一条交互链里检查。这样做的理由是，用户不会只做一次筛选就结束。他可能先筛选，再翻页，再回到目录；如果每一步都只在当前状态下“看起来能用”，组合起来仍然可能让人迷路。
筛选的完成标准不是结果变少，而是用户随时知道自己处于什么状态，并能回到可理解的起点。
深链也是同一个问题的另一面。链接带着用户从页面外部进入某个位置时，页面不能只负责把地址打开，还要让用户知道当前定位到了哪里。无效链接则需要有可继续的路径，不能把用户留在一个空白区域。于是我把深链、分页后的定位和无效链接恢复放在一起回归，而不是只点击默认入口。
失败状态也要能继续
这次最值得警惕的发现，是加载失败后页面会留下骨架，但没有重试入口，也没有可靠的深链定位。骨架本来是为了告诉用户内容正在到来，失败以后如果它还停在那里，就会制造一种“页面还没加载完”的假象。用户可能反复等待，也可能直接离开，却不知道问题是否可以自行恢复。
最容易采用的错误捷径，是只处理成功状态，等真实请求失败后再说。这样做在截图里几乎看不出问题，因为成功页面看起来完整；但真实使用中，网络波动、返回空结果或链接失效都属于正常边界。一个只在顺利时成立的页面，并没有真正完成交付。
我补上失败重试，同时分别检查加载、空结果、失败和无效链接。这里没有把所有异常都变成一句“请刷新”，因为不同状态需要不同的下一步：加载时继续等待，空结果时调整条件，失败时重试，无效链接时回到有效目录或明确的默认位置。恢复动作越接近原因，用户越不需要靠猜。
一个流程是否可靠，不看它在成功时多顺滑，而看它在失败时能不能把用户送回下一步。
用真实交互收口
改完之后，我没有只看一张手机截图，而是按真实使用顺序做回归：先进入目录，再使用筛选，清空条件后分页，打开深链，故意访问无效链接，最后模拟失败并触发重试。这个顺序很重要，因为很多问题只会在状态叠加以后出现。单点截图能证明“这一刻看起来正常”，不能证明用户走得完一条路径。
我还用3种宽度检查横向溢出，并复核标题换行和次要文字对比度。结果显示，筛选、分页、深链、无效链接恢复和失败重试均通过，3种宽度下没有横向溢出。到这里，验收才从“页面缩进去了”变成了“用户能够完成任务”。
这件事让我重新意识到，响应式改造其实是在重新安排注意力。宽度只是外在约束，真正需要设计的是用户在每个状态下先看到什么、能做什么、失败后去哪里。一个流程成熟的标志，不是它只在默认入口跑通一次，而是它能在不同宽度和不同状态下保持同一条可理解的路径。
下次我会怎么做
下次遇到类似页面，我会先写出手机首屏必须完成的1个任务，再按任务顺序安排目录、标题、筛选和状态。只要一个模块不能帮助用户完成这个任务，就先判断它是否应该后移，而不是急着缩字号或压间距。
接着我会把内容和状态一起设计。标题要能完整辨认，筛选要能清空，分页后要能保持定位，深链要能说明当前上下文；加载、空、失败和无效链接，都要有对应的恢复动作。这样做不是为了把边界情况列得漂亮，而是为了避免用户在页面出问题时失去方向。
最后我会用真实交互和3种宽度收口，至少走完一次“进入—筛选—清空—分页—深链—失败—重试”的路径。手机页面不是桌面页面的缩小版，它更像一条需要重新铺设的路：屏幕变窄只是表象，顺序、选择和恢复方式才决定用户能不能走到终点。