这次改一个授权和表单页面，最开始看起来像一次普通的排版工作：桌面端的授权记录被挤成了窄列，手机端的表单又长又散，几个操作区放在一起，用户很难判断自己下一步要做什么。这样的页面很容易让人把注意力放在间距、宽度和按钮位置上。
但我往下检查时，发现真正棘手的不是成功提交以后页面够不够整齐，而是请求失败以后页面有没有把人带回一条清楚的路。读取失败时没有重试入口，记录不能通过深链直接定位，权限被拒绝以后按钮的状态也需要恢复。更危险的是，再次操作失败时，页面还可能继续显示上一次留下的旧授权码，让人误以为这次操作已经成功。
这让我停下来重新定义这次改造。表面上我是在整理一个页面，实际上是在整理用户面对不确定结果时的判断条件。一个页面是否可靠，不看它在成功时多漂亮，而看它在失败时能不能让人知道发生了什么、还能做什么。
一开始只是排版问题吗
当时最直观的问题确实是布局。桌面端的记录区域被压成窄列，信息互相挤压；手机端表单内容太长，用户需要不断滚动，填写和提交之间的关系变得不明显。这样的体验会让人先想到响应式布局、表格宽度和操作区重排。
这些都要修，但只修这些还不够。因为页面不是一张静态海报，它一直在等待读取、接受输入、发起请求，再根据结果变化。只看成功态，就像只检查门在晴天能不能打开，却不看停电时有没有手电筒。
我一开始也有过一个很自然的念头：先把表单压短、把记录排齐，视觉问题解决以后，其他状态再补。后来发现这个顺序会把最需要判断的部分推到最后。布局决定信息能不能看清，状态设计决定用户能不能继续走；前者是表面秩序，后者是操作安全。
如果不处理失败路径，用户会遇到一种很具体的困境：他看到页面停住了，却不知道是网络暂时失败、权限不足，还是刚才的操作其实已经完成。没有重试入口时，他可能反复刷新；没有深链时，他只能重新找记录；旧敏感字段没有清理时，他甚至会拿过期内容继续判断。
先把页面拆成状态
我选择先列状态矩阵，是因为页面改造最怕只围绕一个顺利流程设计。一次完整操作至少要面对空态、正在读取、读取成功、读取失败、输入不完整、提交中、提交成功、权限拒绝，以及再次失败。每个状态都要回答同一个问题：用户现在看到了什么，下一步能做什么，哪些旧信息必须消失。
这个拆法并不复杂，却改变了检查顺序。空态不是“什么都没有”，而是要说明这里为什么为空、用户是否需要刷新或开始新增。加载也不是简单转一个圈，而是要让用户知道页面还在工作，避免把等待误判成卡死。读取失败更不能只留一行红字，至少要给出能再次尝试的入口，并保留足够清楚的原因。
记录列表补上计数和深链定位，也不是为了让页面看起来更完整。计数帮助用户判断读取是否有结果，深链让他可以从外部入口回到某条记录，而不用在长列表里重新寻找。一个入口如果能把人带到页面，却不能带到目标位置，就只完成了“打开”，没有完成“抵达”。
状态矩阵的价值，是把“异常情况”提前变成页面必须支持的正常情况。
失败以后，下一步必须可见
读取失败时，我先补了刷新重试入口和加载骨架。这里的重点不只是多放一个按钮，而是把等待、失败和恢复之间的关系说明白。加载骨架让用户看到页面结构已经出现，重试按钮则告诉他这次失败不是终点。
如果没有这条恢复路径，用户往往只能靠猜。有的人会连续点击原来的操作，有的人会直接关闭页面，还有的人会把浏览器刷新当成唯一办法。每种猜法都可能制造新的请求，或者让用户丢掉刚填好的内容。清晰的重试入口把行动范围收窄了：重新读取这件事可以做，其他状态暂时不要重复提交。
权限拒绝是另一种失败。它和暂时读取失败不能用同一套提示，因为重试不一定能解决权限问题。更重要的是，403 以后按钮不能永远停在不可用或加载中的状态。模拟验收时，我专门检查了拒绝之后按钮能否恢复到可理解的状态，确保用户不会被困在一个看似还在处理、实际已经结束的界面里。
我没有用真实发码来验证这些写入动作，是因为那会把页面验收和真实外部影响混在一起。这里真正要验证的是界面如何处理结果，不是制造一条真实授权记录。用拦截和模拟请求，可以检查空态、失败、恢复、校验和权限拒绝，同时避免生成真实凭证。这是一个带理由的保守决策：先验证状态转换，再把真实写入作为独立风险处理。
最容易漏掉的是旧数据
这次最值得记住的细节，出现在“再次发码失败”这个场景。第一次操作成功以后，页面上已经有一段授权码。用户再次发起操作时，如果新请求失败，旧授权码仍然留在画面上，视觉上就会产生一个非常危险的暗示：页面没有显示新的成功消息，但那段码还在，所以是不是这次也成功了？
这不是普通的清屏问题。敏感数据一旦和当前操作混在一起，用户就无法判断它属于哪个结果。即使旧内容本身没有泄露给别人，它也可能诱导用户复制、保存或继续使用错误的值。失败时清理旧敏感数据，不是为了让界面更干净，而是为了阻止旧结果冒充新结果。
我因此把清理动作放在再次操作开始和失败处理的边界上：新请求开始前，不让旧结果继续代表当前流程；请求失败后，页面明确回到可恢复状态，用户看到的是失败原因和下一步，而不是一段无法归属的旧内容。这个判断也适用于其他页面：旧验证码、旧下载链接、旧订单状态、旧的表单回显，都不能因为“暂时有内容”就被默认保留。
错误捷径是只验收成功提交，把失败当成异常分支，认为真实环境里遇到再补。这样做的代价很大，因为失败态往往比成功态更能暴露状态管理的问题。成功时所有字段都可以被新结果覆盖，失败时则最容易留下半旧半新的画面。只要用户需要自己猜，页面就已经把风险转交给了他。
用模拟请求验收整条恢复链
这次验收不是只点几遍按钮，而是按状态逐项走。先检查空态和加载中的骨架，再模拟读取失败，确认失败提示和刷新入口出现；点击恢复后，确认列表能重新出现。接着检查输入不完整时是否阻止继续，深链能否定位到目标记录，无效深链是否能回到合理位置。
然后再模拟权限拒绝，观察按钮是否恢复，而不是停在不可解释的状态。针对再次操作失败，则确认旧授权码是否消失。最后还检查模拟生成中和成功状态，确保为了修失败路径，没有把正常路径弄坏。实际检查还覆盖了 3 个宽度、键盘操作、触控区域、对比度和控制台错误，重点不是截图好不好看，而是每个状态能不能被稳定触达。
这套方法的核心，是把“页面验收”改成“状态转换验收”。每一项都要有进入条件、用户可见结果和恢复动作。只要其中一个状态没有出口，就不能因为主流程成功而宣布完成。
一个成熟的改造流程，可以压缩成 4 个问题：页面有哪些状态？每个状态告诉用户什么？用户下一步能做什么？失败时哪些旧数据必须清掉？这 4 个问题既适用于授权页面，也适用于支付、导入、上传、审批和任何会产生敏感结果的表单。
下次我会怎么做
下次遇到页面改造，我会先从状态而不是样式开始。先记录空态、加载、成功、失败、权限拒绝和再次失败，再看每个状态的出口在哪里。这样做不是降低对视觉的要求，而是先保证视觉变化没有遮住真正的交互风险。
我会把每个失败状态都写成一个小问题：用户是否知道失败发生了？是否知道原因的大致类别？有没有一个明确的恢复入口？如果重新操作，旧结果是否会误导他？如果答案有一个是否定的，这个状态就还没有完成。
我也会继续优先使用模拟请求验证写入动作。真实发码、真实保存和真实发布，都应该单独列出影响范围，在页面状态已经被验证以后再决定是否执行。这样既能覆盖足够多的边界，又不会为了证明按钮能工作而制造不必要的外部结果。
这件事让我重新意识到，页面改造不是把信息摆得更漂亮，而是把不确定性摆得更诚实。用户不一定要求系统永远成功，但他需要知道失败以后还能去哪儿。一个流程成熟的标志，不是它只跑通一次，而是它在失败、恢复和再次失败之后，仍然给人留着一条清楚的路。