登录流程与错误处理

登录接口不是「查一下」

很多人以为登录接口就是：

接收账号密码 -> 查用户 -> 比密码 -> 返回成功

真上线后你会发现，一个登录请求要经过很多道检查，每一步都可能出错。下面是我最终梳理出的登录流程：

密码验证

验证密码时，用和注册时相同的算法对「用户输入的密码 + 该用户自己的盐」做哈希，然后与数据库里的 password_hash 比较。只在内存中做，不打印、不落日志。

账号状态检查

密码对了还不够，还要看账号状态：

• 已冻结：管理员封禁，登录被拒绝。
• 邮箱未验证：可以登录，但功能受限，提示去验证。
• 需要重置密码：强制引导用户改密后再进入。

状态判断要和风控联动：同一个状态，在高风险场景下处理更严格。

错误提示的艺术

错误提示是认证系统最容易泄露信息的地方。

错误示范：

• 「该账号不存在」——攻击者拿这个提示就能批量探测哪些账号注册过。
• 「密码错误，还剩 3 次机会」——同样泄露账号存在性。

正确做法：统一提示「账号或密码错误」。

这不是为了敷衍用户，而是最小暴露原则：不让攻击者通过接口行为一点一点摸清你的用户数据。真正忘记密码的用户，走「找回密码」流程解决，不需要靠报错提示来判断。

登录结果的审计

无论成功还是失败，登录都要记录审计日志：

event: login
user_id / 尝试的账号
ip, device, 地域
result: success / wrong_password / locked / risk_blocked
created_at

这些日志后面会成为风控和账号安全事件调查的唯一线索。审计日志要防篡改，并且对「失败」要能按账号、IP、设备聚合统计（下一节展开）。

小结

登录流程的关键不只是「密码对不对」，而是把限流、状态、风险、审计都串起来。错误提示要统一，日志要完整，这样系统既安全又可运营。

下一节专门讲防暴力破解——登录接口最容易被打的地方。

上一章节

盐与慢哈希

下一章节

防暴力破解与登录限流