报错那一刻，才是用户真正开始用你的产品：边界情况不是细节

几乎每个早期项目的第一次演示都很顺：网络是好的，数据是提前准备好的，输入框里填的也都是标准格式。然后产品上线第一周，用户走到第三步就卡住了——界面弹出一句「操作失败，请稍后再试」，没有解释，没有下一步，也没人知道刚才那笔到底有没有成功。

演示走的是唯一顺畅的那条路，用户走的是剩下的所有路。产品真正的样子，是在出错的那几秒钟里被定义的。

一根十段的链条，端到端只剩六成

很多团队对稳定性的直觉是「大部分情况没问题」。数学不这么算：一个 10 步的流程，每一步成功率 95%，端到端走得通的概率是 0.95 的 10 次方，约 60%；12 步就掉到 54%。也就是说，每两个用户里就有一个人的第一次是失败的，而这种失败你在自己的演示里从来没见过。

更麻烦的是它不会再演示一次给你看。它出现在地铁没信号的那两分钟里，出现在用户填了 8 分钟的表单按下提交那一刻，出现在第三方接口开始限频的时候。这些场景在开发机上很难复现，但它们是用户每天真实遇到的东西。

最常见的三种失败界面

• 把空白当空状态。列表一条数据都没有时只留一块白屏，用户分不清是还没数据、加载失败，还是自己权限不对。空状态至少要说清一句话：现在为什么是空的，下一步该点哪里。
• 把技术日志贴给用户。「请求超时 500」「参数校验未通过」这类文案对开发有用，对用户是噪音。雅各布·尼尔森在那套经典可用性原则里专门有一条：错误信息要用大白话说清问题，准确指出哪里错了，并给出可以马上执行的解决建议。
• 网络卡住时的重复提交。按钮点了没反应，用户自然会再点三下。如果接口没有幂等键、重试没有退避和抖动，这三下可能变成三笔订单、三封邮件、三次扣款。AWS 公开的架构建议里也在强调同一件事：重试要退避、要加随机抖动，否则重试本身会把故障放大。

把「失败清单」当成需求的一部分

可靠的团队不是不写错的人，而是早就列好会错的地方。开工前把每条主流程的失败点单独写进需求表：第三方接口挂了怎么办，上传中断怎么续，两边数据冲突以谁为准，退款失败由谁兜。这份清单通常一天就能写完，却能省掉上线后两周的救火。

对早期团队，我们建议每次迭代固定做三件事：

• 给每条失败准备三句话。发生了什么、现在该怎么办、联系谁。别写「上传失败」，写「文件超过 50MB，压缩后再试；仍然失败就把截图发群里 @ 值班」。
• 让「重试」真的是重试。写操作加幂等键，重复点击只生效一次；读取失败要给用户一个明确的重试按钮，而不是让他刷新整页——刷新会把刚填的 8 分钟一起冲掉。
• 上线前专门走一遍失败路径。把第三方接口掐掉、把限速调到 3G、故意输错一位卡号，看产品还能不能体面地告诉用户发生了什么。这一遍通常花两个小时，发现的问题比一周正常测试还多。

51kaifa.app 交付早期项目时，需求表里有固定的一栏叫「失败与边界」：每个接口超时、每次第三方调用失败、每种空数据，都要提前写好用户看得到的一句话和一个能点的按钮。这些条目看着琐碎，却是用户第一次就能用顺的关键，也决定了他还愿不愿意有第二次。

← 返回资讯中心