应使用防抖的oninput配合blur、submit、change事件校验密码一致性，通过setcustomvalidity动态控制原生验证状态，并在每次校验时重新读取dom值以确保可靠性。
为什么不能只靠 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只检查非空，不参与一致性判断，别指望它帮你挡掉空确认密码
HTML 结构与基础约束怎么配才不翻车
纯 HTML 无法真正校验一致性——type="password" 和 required 只提供基础提示，真验证必须交由 JavaScript。浏览器内置的 pattern 或 required 都不关心两个字段是否相等。
常见错误现象：input[type="password"] 没绑定事件，点提交时毫无反应；或只比对了值但没同步反馈（比如没清空第二次输入框、没加红框提示）。
- HTML 层只负责结构清晰：给两个
<input>分别设id="password"和id="confirm-password"，便于 JS 获取 - 不要依赖
name相同来“自动关联”，容易混淆，也不利于后续取值 - 避免在
onchange或onblur中直接弹alert()，体验差且移动端不友好 - 推荐监听
input事件（实时响应），而非change（失焦才触发）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
