密码框用 autocomplete="new-password"，验证码框用 autocomplete="one-time-code"（短信）或 autocomplete="off"（图形），且 name/id 避免敏感词；参数独立提交，后端严格校验时效、唯一性及字符清洗。
密码输入框怎么用 autocomplete 避免被浏览器自动填充干扰验证码
浏览器自动填充密码会覆盖用户手动输入的验证码，导致表单校验失败。关键不是“关联”，而是隔离：让密码字段和验证码字段在浏览器看来互不相关。
实操要点：
-
autocomplete="new-password"必须加在密码输入框上（不是"off"，后者在现代浏览器中已基本失效） - 验证码输入框必须设为
autocomplete="one-time-code"（针对短信/邮件验证码）或autocomplete="off"（图形验证码），且 name 和 id 不能含password、pwd、code等易被启发的词，比如用name="vfy_token"比name="verify_code"更稳妥 - 两个字段的
form属性值要一致（确保同属一个表单），但autocomplete类型必须明确区分，否则 Chrome 会强行合并填充逻辑
验证码输入后怎么安全传给后端校验密码
前端不参与“绑定”逻辑，所有校验必须由后端完成。前端唯一要做的，是确保密码和验证码作为独立参数提交，且传输过程不暴露明文风险。
常见错误现象：400 Bad Request 或后端返回 "invalid captcha" 却确认输入无误——大概率是参数名拼错或 Content-Type 不匹配。
立即学习“前端免费学习笔记（深入）”；
实操建议：
佳蓝点卡销售系统修正版
下载
该版本面向个人用户及小型数字卡销售商开发，具有操作简捷、功能强大等特点，且安全及稳定性突出修正说明：1、纠正了部分页面的翻页错误；2、纠正了后台统计不能清零的错误；3、纠正了后台商品管理修改后出错以及无法彻底删除的错误；4、纠正了注册时不能检测用户名是否存在的错误；5、纠正了用户无法修改密码的错误；6、新增“更多新闻”；7、新增会员登陆验证码；8、去除多余及
- POST 请求 body 中用标准键名，例如：
{ "password": "xxx", "captcha_token": "yyy" }，避免用code、verify等模糊字段名 - 若用
application/x-www-form-urlencoded，确保前端没把 JSON 字符串当字符串值塞进去（常见于用FormData.append('data', JSON.stringify(obj))错误写法） - 图形验证码的 token 通常需配合 session_id 或前端生成的临时 key 一并提交，这个 key 必须由后端下发（如响应头
X-Captcha-Key: abc123），前端存入隐藏域再提交，不能硬编码
为什么 inputmode="numeric" 和 pattern="[0-9]*" 对短信验证码很重要
移动端软键盘类型错配会导致用户输入体验崩坏：字母键盘弹出、无法长按粘贴、甚至触发浏览器密码管理器误识别。
这不是“锦上添花”，而是影响验证码通过率的关键细节：
-
inputmode="numeric"强制数字键盘（iOS/Android 均支持），比type="number"更可靠——后者会触发 spinner 和科学计数法输入，反而破坏 6 位纯数字场景 -
pattern="[0-9]{6}"（假设是 6 位）可激活原生校验 UI，但注意：它只在type="text"下生效；若设为type="tel"，pattern 会被忽略 - 不要用
maxlength="6"替代 pattern 校验——用户粘贴超长验证码时，截断行为不一致（Safari 截前 6 位，Chrome 可能拒粘贴），应靠后端二次校验兜底
后端校验不通过？先查这三个地方
前端一切看似正常，但后端始终报验证码错误，问题往往不在加密或算法，而在状态同步丢失。
高频踩坑点：
- 验证码 token 被多次使用：后端校验后未立即失效（Redis 中未执行
DEL或未设EXPIRE），第二次提交必然失败 - 时间窗口不同步：前端生成时间戳 + 后端验证时钟差 > 300 秒（常见于 Docker 容器未挂载 host 时间），导致签名或时效性校验失败
- 大小写/空格污染：用户复制验证码时带了不可见字符（如
\u200b零宽空格），后端没做.trim().replace(/\s/g, '')清洗就直接比对
真正难调试的，永远是那些没打印日志的中间态——比如验证码生成时用了本地缓存但没落库，换机器部署后 token 根本查不到。
