用户名重复性检查须由后端异步校验，blur时防抖轻量提示，submit时严格拦截；统一用setCustomValidity管理状态，结合AbortController防幽灵响应；校验逻辑应封装为可扩展的Handler链。
用户名重复性检查不能靠 HTML 原生 pattern 或 required 完成，它本质是业务逻辑校验，必须由后端参与。正确做法是：让原生校验管“格式与必填”，把“是否已存在”交给异步请求，在合适时机触发、统一反馈。
分层触发：blur 时轻量提示，submit 时严格拦截
用户输完离开输入框（blur）时，可发起一次轻量查重，仅作友好提示（如显示“✓ 可用”或“⚠ 已被注册”），不阻断提交；真正阻止表单提交的校验，只在 submit 事件中、且原生校验通过后执行。
-
blur触发时调用fetch检查用户名，响应后更新旁边提示文案（如<span id="username-tip"></span>），不做event.preventDefault() -
submit事件开头立刻调event.preventDefault()，先执行form.checkValidity()；若失败，直接form.reportValidity()并返回 - 原生校验通过后，再发起用户名唯一性请求；只有该请求返回“可用”才允许继续提交
用 setCustomValidity 管理状态，不手动操作 DOM 提示
避免在 JS 里反复写 document.getElementById("tip").innerText = "..."。应统一使用原生 API 控制字段有效性：
- 每次查重前，先调
usernameInput.setCustomValidity("")清除旧状态 - 若接口返回“已存在”，调
usernameInput.setCustomValidity("该用户名已被注册") - 这样
form.checkValidity()会自动包含该错误，reportValidity()也能统一弹出浏览器默认提示（或配合 CSS 自定义样式） - 注意：空字符串表示有效，非空字符串才表示校验失败
防抖 + AbortController，避免连点和幽灵响应
用户快速连输或连点提交时，容易发出多个并发请求。最后返回的未必是最新一次的结果，导致提示错乱。
- 对
blur场景加简单防抖（如延迟 300ms 发起请求），避免输入过程中频繁调用 - 为每个 fetch 请求配一个
AbortController，保存其signal - 新请求发起前，先调上一个
abort()；确保只有最后一次请求能生效 - submit 中的查重也需同样处理——哪怕只执行一次，也要防止用户中途修改又点提交
责任链式组织，便于扩展与灰度
当校验项增多（如加手机号实名核验、邮箱域名白名单、设备风险识别），硬编码在 submit 里会越来越难维护。
- 把每类校验封装成独立 Handler，例如
UsernameUniquenessHandler、EmailDomainHandler - 每个 Handler 的
execute()方法返回Promise<boolean></boolean>，成功返回true，失败返回false并设置对应字段的setCustomValidity - submit 中按顺序执行 Handler 链，任一返回
false就中断并聚焦首个错误字段 - 不同端（H5 / 小程序 / App）可动态启用或跳过某些 Handler，无需改主流程
