登录页面

登录页面的登录页面第一行代码，往往决定了用户对产品的登录页面全部信任。去年秋天，登录页面我帮朋友排查一个后台系统的登录页面登录故障。用户反馈“密码明明是登录页面对的，就是登录页面进不去”。打开浏览器控制台，登录页面发现登录按钮点击后，登录页面页面只是登录页面轻微抖动了一下，然后清空了密码框。登录页面没有报错，登录页面没有提示，登录页面连网络请求都没发出。登录页面问题出在哪？登录页面一个被遗忘的`event.preventDefault()被错误地绑定在了表单提交事件上，而真正的登录页面校验逻辑被塞进了一个从未触发的回调里。用户看到的“无反应”，其实是前端在沉默中崩溃。

这种沉默的失败，比任何红色错误提示都更让人恼火。登录页面本质上是一个信任交换界面：用户交出凭证，系统承诺验证并放行。任何延迟、模糊或意外行为，都会直接削弱这种信任。我见过太多产品把精力花在注册流程的动画上，却让登录按钮在移动端键盘弹起时被遮挡。也见过用`placeholder`代替`label`的设计，用户输入时提示文字消失，输完忘了自己填的是手机号还是邮箱。

说个具体的。某电商App的登录页，输入框在聚焦时边框变蓝，但错误状态用的是同样的蓝色。用户输错密码，点击登录，按钮转圈两秒，然后页面刷新，输入框清空。没有任何文字说明。我连续试了三次才意识到是密码错误，而不是网络问题。后来看他们的用户反馈，大量投诉集中在“登录没反应”。技术团队的解释是“请求超时后重置了表单状态”，但用户感知到的就是“它坏了”。

好的登录页面不需要花哨。它需要三件事：明确的输入反馈、即时的错误说明、以及不丢失用户已输入的内容。输入反馈包括聚焦状态、键盘类型（数字键盘用于手机号，密码键盘用于密码）、以及大写锁定提示。错误说明要具体到字段，比如“密码需包含至少一个数字”，而不是笼统的“登录失败”。不丢失内容意味着，当用户切换标签页或误触返回键时，已经填好的手机号应该还在。

我自己的习惯是，拿到一个新网站，先故意输错密码。看它怎么回应。如果它只是抖动一下输入框，没有文字提示，我会对这个产品的技术严谨性打一个问号。如果它把密码框清空，但保留了用户名，那还算及格。如果它连用户名都清空，并且不说明原因，我基本会关掉页面。这不是苛刻，是登录页面暴露了后端错误处理的设计水平。一个连“密码错误”都不愿意明确告诉用户的系统，很难让人相信它会妥善保管其他数据。

还有一类问题出在自动填充上。浏览器保存了密码，用户点击输入框，下拉选择账号，但页面上的JavaScript监听了`input`事件，却没有监听`change`或`autocomplete`。结果自动填充的值进入了DOM，但框架的状态里还是空的。用户点击登录，前端校验说“请输入密码”。用户看着已经填满的密码框，陷入困惑。这种bug在React和Vue项目里反复出现，每次都要重新踩一遍。

登录页面的代码通常很短，但它的状态机并不简单：空闲、输入中、校验中、请求中、成功、失败、锁定、验证码挑战。每个状态之间的转换都需要明确的视觉和文字反馈。我见过一个银行App，在请求中状态把整个表单禁用，但没有显示加载指示器。用户以为页面卡死，疯狂点击，结果触发了多次请求，账号被临时锁定。这就是状态设计缺失的代价。

最后说一个细节。很多登录页面在移动端把“忘记密码”链接放在密码框右侧，用很小的字号。手指点上去，要么没反应，要么点到了密码框。正确的做法是把点击区域扩大到至少44像素，并且和输入框保持足够间距。这些不是设计规范里的教条，是手指在真实屏幕上的物理限制。登录页面是产品的门，门把手如果硌手，没人会想进去看看里面的装修。