错误提示必须作为 input 的同级兄弟节点插入，使用 或 紧跟其后，配合 aria-describedby、setcustomvalidity() 与 reportvalidity() 同步控制状态，确保可访问性、视觉关联性与 dom 稳定性。
表单验证失败时的提示不能靠 title 或 placeholder 顶替，也不能塞进 label 里——否则屏幕阅读器读不准、视觉动线断裂、移动端根本看不到。
错误信息必须插在 input 后面（同级兄弟节点）
这是唯一能同时满足可访问性、视觉关联性和 DOM 稳定性的做法。浏览器原生验证气泡不可控，而自定义提示必须和对应控件保持 DOM 邻近关系，否则 aria-describedby 指向再准，焦点切换时语音反馈也常失效。
- 每个
input后紧跟一个<div class="error"></div>，用 CSS 的display: block和margin-top控制间距，避免行内元素换行错位 - 不要用
innerHTML = ""清空后忘记重置visibility: hidden，否则后续报错不显示 - 多个字段共用同一段 JS 验证逻辑时，别写
document.querySelector(".error")——永远只改第一个；推荐给input加data-error-target="#error-username"，JS 里用el.dataset.errorTarget精准定位
setCustomValidity() 必须配 reportValidity() 才生效
setCustomValidity() 只是存文案，不触发校验、不弹提示、不改样式。它设完就“静音”，直到你手动调 reportValidity() 或用户触发 submit。
- 传非空字符串（如
"邮箱格式不对"）才标记为无效；传""（空字符串）才是重置，null或undefined都无效 - 监听
blur做即时反馈比监听input更合理——后者每打一个字都校验，体验卡顿 - Chrome/Firefox 支持良好，Safari 对自定义消息的字体大小等样式控制较弱，别强依赖
标红提示要用 :invalid:user-invalid 组合伪类
只用 :invalid 会导致页面一加载就给空必填项标红，用户还没碰就吓一跳；:user-invalid 要求用户至少有过交互（focus + blur、输入后删空），才是真正“操作后才高亮”的语义。
- 生产环境建议写成
input:invalid:user-invalid，兼顾逻辑准确与渐进增强 - 别用 JS 动态加
class模拟红框——容易和原生验证状态冲突，比如清空错误后 class 还挂着 -
select元素默认不触发视觉错误反馈，必须配合 JS 主动classList.add("error")，且其 HTML 结构里要带空value=""的默认选项
异步提交失败后，字段级错误必须按 name 映射并清理旧提示
后端返回的错误结构（如 {"email": ["已被注册"], "password": ["至少8位"]}）和前端 input[name] 必须严格对齐，大小写、下划线/驼峰都不能差——否则映射错位，错误堆在错误字段下。
- 每次渲染新错误前，先执行
form.querySelectorAll(".error-message").forEach(el => el.remove())，清空所有旧提示 - 错误容器建议用
<span class="error-message"></span>，紧跟在对应input后面，而非父容器末尾 - 服务端字段名和
input[name]不一致时，宁可改后端 JSON key，也不要前端硬写映射表——维护成本高、易出错
最易被忽略的是：验证状态和 DOM 提示必须同步更新。比如用户修正了邮箱，你清了 setCustomValidity("")，但忘了移除 .error 类或隐藏对应 .error-message，红框就一直挂着——这不是样式问题，是状态管理断层。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
