一个提交按钮，网页用户点了三次都没反应。易用第四次他放弃了，网页关掉页面。易用后台日志显示，网页三次请求全部成功。易用问题出在按钮点击后没有任何视觉反馈——没有loading，网页没有禁用，易用没有文字变化。网页用户以为没点上，易用实际数据已经写进数据库了。网页这个bug不报错，易用不崩溃，网页但它让用户白跑三趟。易用

网页易用性的网页bug跟功能bug不一样。功能bug是"点不了"，易用性bug是"不知道该不该点"。前者测试能抓到，后者得靠人坐在那儿用才看得出来。

表单验证：错误提示的三种死法

第一种，提交后才告诉你哪里填错了。十来个字段，顶部弹一行红字"请检查输入"。用户得自己一个个找。第二种，输入框变红但不说原因。用户盯着那个红框，不知道是格式不对、必填没填、还是字数超了。第三种更绝——错误提示写了，但写的是"输入无效"。什么叫无效？我输入的手机号是11位啊。

我见过一个注册页，密码要求"8-20位，含大小写字母和数字"。用户输到第7位的时候没有任何提示，点提交才弹出来。如果实时显示一个强度条或者逐条打勾的规则列表，这个bug就不存在了。技术上难吗？一个正则的事。

移动端的点击区域

手机上有个常见问题：可点击元素太小。苹果的人机界面指南建议最小44×44像素，谷歌建议48×48。实际项目中大量按钮只有文字本身那么大，旁边两个按钮间距不到10像素。拇指点上去，要么点不中，要么点错。

有个电商App的"加入购物车"和"立即购买"并排放在底部，两个按钮之间没有间隙。用户想加购物车，结果直接下单了。这个设计在桌面端没问题——鼠标精准。移动端就是灾难。修复方式很简单：加间距，或者把次要操作改成文字链接。但很多团队不做，因为"设计稿就是这样"。

滚动劫持与焦点丢失

有些页面会劫持滚动行为。你往下滑，它给你弹一个全屏弹窗。你关掉弹窗，页面跳回顶部了。用户之前浏览的位置全丢了。更隐蔽的一种：弹窗打开后，焦点没有锁在弹窗内。用户按Tab键，焦点跑到背后被遮住的页面上去了。屏幕阅读器用户完全懵了——读的内容和看到的内容对不上。

还有键盘用户的经典痛点：自定义下拉菜单。用鼠标点开一切正常，用键盘Tab过去，按回车没反应，按空格也没反应。因为开发者只绑了click事件，没处理keydown。这个bug在测试阶段很难发现——测试人员通常用鼠标。

加载状态与空状态

一个列表页，数据没加载出来之前是白屏。用户不知道是在加载、加载失败了、还是本来就没数据。三种状态长得一模一样。加个骨架屏或者"加载中"的文字，成本极低，但很多页面就是不做。

空状态也一样。搜索无结果，页面一片空白。用户怀疑是不是搜索功能坏了。如果显示"没有找到与'xxx'相关的结果，试试其他关键词"，体验完全不同。这不是锦上添花，这是告诉用户"系统正常，只是没匹配到"。

这些bug为什么长期存在

功能测试能过，自动化测试能过，代码review也看不出问题。它们不影响数据流转，不影响接口调用，不影响业务逻辑。它们只影响一件事：用户用起来顺不顺。而这件事，往往要等到用户流失率上升、客服收到投诉、或者某个产品经理自己用了一遍之后，才会被注意到。

修起来通常不复杂。一个CSS过渡，一个aria-label，一个防抖处理，一个最小点击区域。难的是意识到它们的存在。做页面的人太熟悉自己的页面了——他知道按钮在哪，知道怎么操作，知道每一步会发生什么。用户不知道。用户只会点一下，没反应，再点一下，还没有，然后走了。