不能只靠oninput实时比对，因其在用户输入首字符时即触发（如主密码为空、确认密码为"a"），导致误报、界面闪红、干扰体验；真实校验应聚焦blur（失焦反馈）和submit（兜底拦截）两个时机，并配合防抖或change事件弥补移动端兼容性问题。
为什么不能只靠 oninput 实时比对两次密码
用户刚在确认密码框敲第一个字符，主密码框还是空的，oninput立刻触发比对，"" !== "a" 就报错——界面闪红、提示跳动，干扰输入节奏。这不是校验，是骚扰。
真实意图是“用户填完两个字段后确认是否一致”，不是“边输边判死刑”。所以 oninput 必须配合防抖（如 setTimeout 延迟 300ms），否则 DOM 频繁操作还可能卡顿；更稳妥的做法是把核心校验时机放在 blur 和 submit 两个节点。
-
blur负责用户离开确认密码框时的即时反馈（比如 Tab 切出、鼠标点别处） -
submit是兜底：用户直接点提交、绕过blur、甚至禁用 JS，都必须拦截 - 移动端需额外监听
change：iOS Safari 软键盘收起有时不触发blur，change更可靠
如何用 setCustomValidity 实现原生兼容的校验链
浏览器原生表单验证 API（Constraint Validation API）能和 required、minlength 等属性无缝协同，不用自己写红框、显隐提示元素。
关键不是“设错误”，而是“清空错误”：每次比对后，无论成功失败，都要调用 setCustomValidity()。否则上次的错误会残留，导致后续提交一直被拦。
- 比对失败时：
confirmInput.setCustomValidity("两次输入的密码不一致") - 比对成功时：
confirmInput.setCustomValidity("")（空字符串表示“通过”） - 必须在
blur和submit中都执行该逻辑，不能只做一次 - 不要在
input里反复调用document.getElementById()，提前缓存passwordInput和confirmInput引用
submit 事件里必须重跑比对逻辑，不能信缓存结果
用户可能跳过 blur（比如鼠标直接点提交按钮）、也可能用开发者工具改 DOM 值绕过前端 JS。所以 form.addEventListener('submit', ...) 中必须重新取值、重新比对。
常见错误是只在 blur 里设了个全局变量 isPasswordMatch = true，然后在 submit 里直接 if (!isPasswordMatch) —— 这完全不可靠。
- 在
submit处理函数中，重新获取passwordInput.value.trim()和confirmInput.value.trim() - 比对后若失败，必须调用
event.preventDefault()，否则表单照常提交 - 可封装成独立函数如
validatePasswordMatch()，在blur、change、submit三处复用，但每次调用都应重新读 DOM 值 - 注意：HTML 的
required只检查非空，不参与一致性判断，别指望它帮你挡掉空确认密码
移动端和 autocomplete 对 onBlur 的干扰怎么处理
iOS Safari 在自动填充密码后，有时不触发 blur；Android 键盘切换输入框，blur 和 focus 顺序也不稳定。仅靠 blur 会漏掉一批真实用户。
解决方案不是放弃 blur，而是补监听 change + 合理利用 autocomplete 属性。
- 给密码框加
autocomplete="new-password"（主密码）和autocomplete="new-password"（确认密码），避免浏览器误填旧密码覆盖用户输入 - 在
blur回调里加个兜底：如果检测到confirmInput.value非空但未校验过，立即手动触发一次比对 - 同时绑定
change事件，尤其在 iOS 上，软键盘收起后它比blur更准 - 不要用
alert()提示，改用内联span或修改input的title属性，适配移动端弹窗限制
setCustomValidity 的状态」——哪怕只是成功一次，不调用 setCustomValidity("")，这个字段就永远处于 invalid 状态，后续任何提交都会被浏览器原生机制拦截。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
