密码一致性校验须用blur+submit+change三事件触发，每次均需重新取DOM值并调用setCustomValidity()动态设状态，禁用oninput实时比对以防误报。
密码、邮箱、验证码等字段的「两次输入一致性」校验，不能只靠 oninput 实时比对，否则用户刚敲第一个字符就报错，体验极差。核心解法是：用 blur + submit（+ 移动端 change）三节点触发校验，配合 setCustomValidity() 动态控制原生验证状态，且每次校验都必须重新读取 DOM 值。
为什么不能只监听 input 事件做实时比对
用户在确认密码框输入第一个字符时，主密码框很可能还是空的，oninput 立刻触发 "" !== "a" 判定，界面闪红、提示跳动——这不是校验，是干扰。真实需求是“填完两个字段后确认是否一致”，不是“边输边判死刑”。即使加防抖（如 setTimeout 延迟 300ms），仍无法覆盖用户跳过确认框直接点提交、或用开发者工具改 DOM 的情况。
必须监听的三个事件节点及其分工
blur：用户离开确认密码框时反馈（Tab 切出、鼠标点别处），提供即时视觉响应submit：兜底拦截，防止绕过 blur 或禁用 JS 后非法提交change（仅移动端 iOS Safari）：软键盘收起有时不触发 blur，change 更可靠
- 三者都应调用同一校验函数，例如
validatePasswordMatch() - 不要在
input里反复调用document.getElementById()，提前缓存passwordInput和confirmInput引用 - 每个事件回调中，都需重新获取
passwordInput.value.trim()和confirmInput.value.trim()，不可信任何缓存变量
用 setCustomValidity 正确管理验证状态
setCustomValidity() 不是“设错误”，而是“设状态”：空字符串 "" 表示通过，非空字符串表示失败。关键在于每次比对后都必须调用它，否则上次错误会残留，导致后续提交一直被拦。
立即学习“前端免费学习笔记（深入）”；
- 比对失败时：
confirmInput.setCustomValidity("两次输入的密码不一致") - 比对成功时：
confirmInput.setCustomValidity("") - 必须在
blur、change、submit三处都执行该逻辑，缺一不可 - 在
submit处理函数中，若比对失败，必须显式调用event.preventDefault()，否则表单照常提交
容易被忽略的关键细节
很多人以为 required 能挡掉空确认密码，其实不能——required 只检查非空，不参与一致性判断。更隐蔽的问题是：把校验结果存在全局变量（如 isPasswordMatch = true），然后在 submit 里直接读这个变量。这完全不可靠，用户可能跳过 blur，也可能用 DevTools 直接改 DOM 值。真正的安全做法，是在每次 submit 触发时，重新取值、重新比对、重新调用 setCustomValidity()，一步都不能省。
