这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
登录流程与错误处理
登录接口不是「查一下」
很多人以为登录接口就是：
接收账号密码 -> 查用户 -> 比密码 -> 返回成功真上线后你会发现，一个登录请求要经过很多道检查，每一步都可能出错。下面是我最终梳理出的登录流程：
生产级登录流程
用户在登录页提交账号密码
限流检查
步骤 1 · 判断账号 / IP / 设备维度，防暴力破解按账号查找用户
步骤 2 · 动作找不到不区分「账号不存在」慢哈希验证密码
步骤 3 · 动作密码错误同样统一提示检查账号状态
步骤 4 · 判断冻结 / 未验证邮箱 / 需重置密码评估登录风险
步骤 5 · 判断新设备 / 异地 / 行为异常高风险时触发 MFA
步骤 6 · 判断二次验证，见第 7 章创建会话，签发凭证
步骤 7 · 结果Cookie / Access Token + Refresh Token登录成功，写入审计日志
密码验证
验证密码时，用和注册时相同的算法对「用户输入的密码 + 该用户自己的盐」做哈希，然后与数据库里的 password_hash 比较。只在内存中做，不打印、不落日志。
账号状态检查
密码对了还不够，还要看账号状态：
- 已冻结：管理员封禁，登录被拒绝。
- 邮箱未验证：可以登录，但功能受限，提示去验证。
- 需要重置密码：强制引导用户改密后再进入。
状态判断要和风控联动：同一个状态，在高风险场景下处理更严格。
错误提示的艺术
错误提示是认证系统最容易泄露信息的地方。
错误示范：
- 「该账号不存在」——攻击者拿这个提示就能批量探测哪些账号注册过。
- 「密码错误，还剩 3 次机会」——同样泄露账号存在性。
正确做法：统一提示「账号或密码错误」。
这不是为了敷衍用户，而是最小暴露原则：不让攻击者通过接口行为一点一点摸清你的用户数据。真正忘记密码的用户，走「找回密码」流程解决，不需要靠报错提示来判断。
登录结果的审计
无论成功还是失败，登录都要记录审计日志：
event: login
user_id / 尝试的账号
ip, device, 地域
result: success / wrong_password / locked / risk_blocked
created_at这些日志后面会成为风控和账号安全事件调查的唯一线索。审计日志要防篡改，并且对「失败」要能按账号、IP、设备聚合统计（下一节展开）。
小结
登录流程的关键不只是「密码对不对」，而是把限流、状态、风险、审计都串起来。错误提示要统一，日志要完整，这样系统既安全又可运营。
下一节专门讲防暴力破解——登录接口最容易被打的地方。