纯css无法可靠实现复杂表单验证样式，必须配合js控制状态；:valid/:invalid初始即触发是规范行为，非bug；延迟反馈可用:user-invalid（新safari支持）或:not(:placeholder-shown):invalid（兼容性好）；父容器无法响应伪类，需js加类；后端错误、多条件校验等必须用data属性或状态类。
纯 CSS 无法可靠实现“复杂”表单验证样式，必须配合 JS 控制状态时机和语义；:valid/:invalid 只响应原生约束且初始即触发，容易一打开就红边框，这不是 bug，是规范行为。
为什么 :valid 和 :invalid 一加载就生效
浏览器对 :invalid 伪类的判定基于原生验证属性（如 required、type="email"、pattern），且空的 required 输入框在 DOM 加载完成时即匹配 :invalid。这不是渲染延迟，而是标准定义——用户还没操作，样式已生效。
-
<input required>→ 初始为空 → 立刻匹配:invalid -
<input type="email">→ 初始值为空字符串 → 多数浏览器（Chrome/Firefox）误判为:valid，Safari 可能不应用任何伪类 -
<textarea pattern=".+"></textarea>→ 必须有pattern或required才会参与验证，否则:invalid永远不匹配
如何延迟验证反馈，只在用户操作后显示
目标是避免“页面一开就报错”，核心思路是排除未交互状态。目前最实用的两种路径：
- 用
:user-invalid：语义最准，只在用户输入后验证失败才生效，但 Safari 直到 16.4+ 才稳定支持（2026 年多数新设备已覆盖，老 iOS 仍需降级） - 用
:not(:placeholder-shown):invalid：依赖placeholder属性，用户至少输入/删除过一次内容才会触发，兼容性好（Chrome 47+/Firefox 51+/Safari 9.1+），但无法覆盖没设 placeholder 的字段 - 绝对不要用
:focus:invalid做错误提示——用户刚点进去还没输，就亮红边，体验更差
为什么父容器或 label 无法响应 :invalid
:valid 和 :invalid 是元素级伪类，只能作用于 input、select、textarea 自身，不能向上影响父级或跨层级兄弟节点。
-
input:invalid + label只能影响紧挨着的、顺序在后的label，且要求两者同级 -
form:has(input:invalid)理论上可行，但 Safari 对:has()支持仍不稳定（截至 2026 年 7 月） - 真正可用的方案是 JS 主动给父容器加类，例如
<div class="form-field form-field--invalid"> <input><span class="form-field__message"></span> </div>，再写.form-field--invalid .form-field__input和.form-field--invalid .form-field__message
何时必须放弃纯 CSS，改用 data- 属性或状态类
当验证逻辑超出原生能力时，CSS 伪类完全失效：
- 后端返回的字段级错误（如“该邮箱已被注册”）→
:invalid不会响应，必须用data-error="email-taken"配合 CSS 变量 - 多条件组合校验（如“密码和确认密码不一致”）→ 没有对应 HTML 属性，JS 是唯一入口
- 需要同步更新
aria-invalid、aria-describedby等可访问性属性 → 必须由 JS 控制 - 移动端 Safari 对
:user-invalid支持弱，且reportValidity()弹窗不可关闭 → 实际项目中，主流框架（Bootstrap、Ant Design）全采用is-valid/is-invalid类统一驱动样式
真正容易被忽略的是：CSS 伪类反馈永远滞后于 JS 校验结果——哪怕你刚调用 input.setCustomValidity("xxx")，:invalid 也不会立刻重绘，得靠 reportValidity() 或切换 class 触发。别指望它实时。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
