:user-invalid 更适合“用户操作后反馈”，因为它仅在用户聚焦又失焦或输入后验证失败时激活，不响应初始空值，语义更精准，且需浏览器支持（chrome 102+、firefox 119+、safari 16.4+）及原生验证约束。
为什么 :user-invalid 比 :invalid 更适合“用户操作后反馈”
:invalid 一加载就匹配空的 required 输入框，而 :user-invalid 只在用户真正聚焦过又失焦（或输入后）且值不合法时才激活——它不关心初始空值，只响应「用户意图 + 验证失败」。这是语义上更准确的状态，也是 Chrome 102+、Firefox 119+、Safari 16.4+ 的标准行为。
常见错误现象：写了 input:user-invalid { border-color: red; } 却没反应，不是语法错，而是浏览器版本不够或没触发“用户交互”。
- 必须有原生验证约束（
required、type="email"、pattern等），否则 :user-invalid 永远不匹配 - 用户至少要 focus → blur 过一次，或输入后删除/改错，才算“操作过”
- Safari 16.3 及更早版本不支持，需用 JS fallback（如添加
.touched类）
:user-invalid 样式写法与常见陷阱
直接写 input:user-invalid 即可，但要注意它和 :focus、:valid 的层叠关系。比如你同时设了 input:focus { outline: blue; } 和 input:user-invalid { border-color: red; }，两者互不冲突，可以共存。
- 别用
!important强行覆盖，优先靠选择器权重控制，例如写成form input:user-invalid -
textarea和select同样支持:user-invalid，但type="text"若无其他约束（如required），永远不进入该状态 - 不要和
:placeholder-shown混用——:user-invalid本身已隐含“用户动过”，加:not(:placeholder-shown)是冗余且可能误判
兼容旧浏览器的降级方案
当目标环境包含 Safari input 或 blur，给元素打标记。
- 监听
blur更稳妥：用户离开字段才判定，避免输入中频繁重绘 - 用
dataset而非 class 控制状态，例如input.dataset.touched = "true" - CSS 写成
input[data-touched="true"]:invalid，这样既复用原生校验逻辑，又延迟视觉反馈 - 注意 reset 表单时要清空
dataset.touched，否则后续提交仍保留红框
JS 自定义校验如何同步到 :user-invalid
:user-invalid 不响应 JS 的 value 修改或 class 切换，它只认表单约束 API 的状态。如果你做了异步校验（比如用户名是否可用），必须调用 setCustomValidity() 才能影响伪类。
- 校验失败：调
input.setCustomValidity("用户名已被占用") - 校验通过：必须调
input.setCustomValidity("")—— 这一步漏掉，元素会永久卡在 :user-invalid - 不需要主动调
reportValidity()，只要用户 blur 过，:user-invalid 就会按最新 validity 状态更新 - 调试时看
input.validity.valid值，比依赖样式更可靠
required 字段在 focus 后立刻 blur，若仍为空，才会触发；但如果用户 focus 后什么都没输就切走，部分浏览器（尤其 Safari）可能不立即判定，得等下一次交互或 submit 才刷新状态。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
