后端必须参与用户名可用性校验，前端仅负责调用fetch并合理处理异步响应、节流、取消请求、状态码解析及setCustomValidity手动控制表单验证，同时后端需限流、缓存、明确定义规则。
用 fetch 检查用户名是否已被注册
后端必须参与，前端单独验证毫无意义。浏览器里任何检查都能被绕过，fetch 只是把「用户输入 → 向服务端问一句 → 得到结果」这个动作做干净。
常见错误是把校验逻辑全塞进 oninput 里反复发请求，没节流、没取消上一次请求、没处理 409/422 等业务状态码。
- 用
AbortController主动取消前序请求，避免旧响应覆盖新结果 - 延迟 300ms 再发起请求（防连打），用户停顿才查
- 只对长度 ≥2 的输入发起请求，太短的不用查（比如 “a”）
- 后端返回
200 { available: true }或409 { error: "username taken" }，前端别只看 HTTP 状态码
HTML 表单里怎么接住这个结果
不能靠 required 或 pattern 实现“是否可用”，它们只管格式，不联网。得靠 setCustomValidity() 手动控制校验状态。
关键点在于：校验异步完成之后，必须显式调用 reportValidity() 或触发一次 checkValidity()，否则表单提交时不会重新评估这个字段。
-
inputElement.setCustomValidity("")表示通过；非空字符串表示失败，内容会作为报错文案 - 不要在
fetch的.then()里直接写form.reportValidity()，它会强制校验所有字段，干扰用户体验 - 只在用户明确提交表单时，或聚焦离开该输入框时，才触发最终判定
为什么不用 constraint validation API 的原生提示样式
因为它的气泡提示（tooltip）位置不可控、样式难改、移动端兼容差，且无法区分“格式错”和“已被占用”这两类不同语义的错误。
更实际的做法是：关掉默认提示，自己用旁边一个 更新文字和颜色。
- 加
novalidate到，彻底禁用浏览器原生校验 UI - 监听
invalid事件仅用于埋点或日志，不用于展示 - 所有提示文案由 JS 控制，方便后续接入 i18n 或统一设计系统
后端接口设计容易被忽略的细节
前端发请求简单，但后端若没做好几件事，整个可用性校验就变成伪需求。
最常踩的坑是没做缓存或没限制频率，导致用户狂点注册时，同一用户名被反复查询，压垮数据库。
- 接口路径建议用
POST /api/v1/users/username/available，不用 GET（避免被 CDN 缓存） - 请求体为
{ "username": "xxx" }，别用 query 参数（长度限制 + 日志泄露风险） - 加 Redis 缓存结果，TTL 设 5–10 分钟，重复查相同用户名直接返回缓存
- 对单 IP 或 token 做限流（如 10 次/分钟），防探测攻击
真正麻烦的从来不是怎么写那三行 fetch，而是前后端对“可用”的定义是否一致——比如是否忽略大小写、是否允许下划线开头、是否把 “admin” 当保留字。这些规则必须写死在接口文档里，而不是靠前端猜。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
