真正有效的暴力破解防护必须在服务端实现，通过redis以ip+用户名为键记录失败次数并设置过期时间，登录成功后清除计数，同时需考虑设备指纹、并发竞争和分布式降级等细节。
HTML5表单提交根本防不住暴力破解
浏览器端的 input[type="password"] 或 required、pattern 这些只是体验层约束，所有校验逻辑都能被绕过——禁用JS、改DOM、直接发POST请求，甚至用curl模拟登录，服务端没防护就等于裸奔。
真正有效的次数限制必须在服务端实现
前端加个「输错3次锁1分钟」的提示毫无意义，除非后端同步记录并拒绝请求。关键不是“怎么写前端”，而是「怎么让后端识别同一用户、累计失败、临时封禁」：
- 用 IP + 用户名（或手机号）组合做键，存到 Redis，
INCR失败次数，EXPIRE设置自动过期（比如60秒） - 每次登录前先查
GET login:fail:192.168.1.100:user123，值 ≥ 3 就直接返回429 Too Many Requests - 成功登录后务必用
DEL login:fail:192.168.1.100:user123清空计数，否则用户永远登不上 - 别只靠IP——NAT环境下多个用户共用一个出口IP，容易误伤；建议优先绑定账号+设备指纹（如User-Agent哈希），再 fallback 到IP
前端能做的只有配合和服务降级
前端唯一靠谱的作用，是减少无效请求、改善体验、防止手滑连点，不是安全防线：
- 提交按钮点击后立即
disabled，防止重复提交（但不能替代后端幂等校验） - 输错时显示倒计时，比如「还有 42 秒可重试」，这个时间必须和服务端 Redis 的
TTL同步，不能前端自己算 - 密码框旁加「显示密码」按钮没问题，但别用
type="text"长期暴露——切回type="password"时确保值没被清空 - 别在前端存失败次数到
localStorage，刷新就丢，且完全不可信
常见错误：把验证码当成万能解药
验证码（CAPTCHA）只防自动化脚本，不防人工肉鸡群或撞库攻击。而且它带来真实代价：
立即学习“前端免费学习笔记（深入）”；
- 无障碍访问失效，视障用户无法登录
- 移动端输入麻烦，尤其数字+字母混合的图片验证码
- 如果验证逻辑在前端校验（比如检查
grecaptcha.getResponse()是否为空），一样能被跳过 - 真正该用验证码的场景，是「异常高频请求触发」，而不是每次登录都弹——否则等于主动赶客
复杂点从来不在怎么写那个「锁3次」的逻辑，而在于：你有没有把用户标识对齐、有没有处理并发写入竞争、有没有考虑分布式部署下Redis单点故障时的降级策略。这些细节漏掉一个，前面全白搭。
