输入框下面那个登录按钮，网站务流是登录的业整个网站最脆弱也最关键的部件。用户敲完密码，程图手指悬停在回车键上，网站务流那一刻系统要做的登录的业远不止“比对字符串”这么简单。

拿我前阵子调试的程图一个电商站来说，登录流程画成图，网站务流能铺满一整张A4纸。登录的业第一层是程图前端校验——邮箱格式对不对、密码长度够不够。网站务流这一步纯粹为了挡掉手滑，登录的业省得把垃圾请求打到服务器上。程图真正的网站务流大头在后头：后端收到请求，第一件事不是登录的业查密码，而是程图查这个IP最近有没有疯狂尝试。防爆破的计数器在Redis里跳着，超过五次，直接弹验证码。你说烦？那也没办法，总比被撞库强。

过了风控这关，才轮到真正的身份核验。数据库里存的是哈希值，不是明文——这年头谁还敢存明文？拿用户输入的密码加盐再哈希，跟库里的比对。这一过程快得离谱，通常几毫秒就出结果。但慢的时候也有，比如数据库连接池满了，或者磁盘IO卡了，用户就卡在“登录中”那个转圈圈上。这时候用户会干嘛？狂点按钮。所以代码里得做防重复提交，不然一个请求没返回，后面排了二十个一模一样的。

密码对了，事情还没完。得发token。现在主流是JWT，一串无状态的东西，服务端不用存session，全靠签名验证。但token发给谁？存哪儿？localStorage还是cookie？这决定着你关掉浏览器再打开，登录态还在不在。我见过不少站点，登录成功后往localStorage塞了个token，结果用户清个缓存就掉线，骂骂咧咧地打电话投诉。

还有个容易被忽略的环节——登录后的回调。业务系统往往不止一个，单点登录（SSO）那边跳转回来，得带上一个临时票据，再拿票据换用户信息。这套流程在流程图里画出来，就是几条交叉的箭头，但实际跑起来，任何一环超时，用户看到的就是“登录失败，请重试”。重试？重试多少次都不管用，因为票据是一次性的，过期就作废。

最后说个扎心的现实：整个流程再严谨，也架不住用户自己把密码设成“123456”。流程图里每个分支都考虑到了，唯独没考虑到人性。所以有些网站开始搞无密码登录——扫码或者短信验证码。流程倒是短了，可短信通道要是被运营商卡了，用户照样进不来。

画流程图的人总想着把所有异常都画进去，但真实世界里永远有流程图外的意外。比如数据库主从延迟，用户刚改完密码，登录时读的是从库，还是旧密码。这种问题，画图时根本想不起来，只有线上爆了才知道。登录这事儿，看着简单，其实就是个不断跟网络、跟安全、跟用户耐心赛跑的活儿。