:valid 和 :invalid 不生效的根本原因是表单控件缺少 required、type、pattern 等原生验证约束；纯 text 输入无约束时恒为 :valid；动态插入需确保属性真实存在于 DOM；它们在输入、失焦、提交时自动计算，权重等同普通类选择器；:user-invalid 可解决初始误红问题，但需注意兼容性与不可逆性；业务逻辑校验必须用 setCustomValidity() 配合 JS。
为什么 :valid 和 :invalid 有时不生效
根本原因通常是表单控件缺少必要的验证约束。浏览器只在元素有 required、type="email"、pattern、min/max 等属性时，才真正触发原生验证逻辑，进而影响 :valid/:invalid 的状态。纯文本输入（如 type="text"）且无其他约束时，始终被视为 :valid。
- 检查是否漏写了
required或语义化type（比如邮箱用type="email"，数字用type="number"） -
pattern必须配合title（可选）和非空值才有意义；空字符串对pattern默认通过，除非加required - 动态插入的表单元素（如 JS 创建）需确保属性在 DOM 中真实存在，而非仅 JS 属性赋值
:valid 和 :invalid 的触发时机与样式优先级
这两个伪类在每次输入、失焦（blur）、提交（submit）时由浏览器自动计算，无需 JS 干预。但要注意：它们的样式权重等同于普通类选择器，容易被更具体的选择器覆盖。
- 写法上推荐用组合形式，例如
input:invalid、input[type="email"]:invalid，避免泛化成:invalid影响全局 - 若同时设置了
:focus样式，:focus:invalid会覆盖单纯:invalid，适合做“聚焦时高亮错误” - 初始加载时，未交互的
required字段默认为:invalid（哪怕为空），这点常被忽略
如何配合 :user-invalid 更精准控制交互后样式
:user-invalid 是较新的伪类（Chrome 107+、Firefox 119+ 支持），它只在用户与字段发生过交互（输入、粘贴、失焦等）后才激活 :invalid 状态，解决“一进页面就红”的体验问题。
- 推荐渐进式写法：
input:invalid:not(:user-invalid)设为低调提示（如边框微灰），input:user-invalid:invalid才设醒目错误色 - 旧浏览器不支持
:user-invalid时，可用 JS 添加class="touched"模拟，再写input.touched:invalid - 注意：
:user-invalid不会回退——一旦触发，即使清空内容再失焦，仍保持该状态，直到下一次有效输入或重置表单
常见误用：把 :valid/:invalid 当作 JS 验证替代品
它们只反映 HTML5 原生约束的校验结果，无法处理业务逻辑（如“密码两次输入不一致”“用户名已被注册”）。这类场景必须靠 JS 控制 setCustomValidity() 手动触发状态。
立即学习“前端免费学习笔记（深入）”；
- JS 中调用
input.setCustomValidity("错误信息")后，该字段立即变为:invalid；传入空字符串则恢复:valid - 务必在每次校验后都调用，否则状态不会更新（例如异步接口返回后忘记重置）
- 不要依赖
checkValidity()返回值直接改样式——应统一用伪类，保持样式与状态同步
required 就万事大吉，却没意识到空字符串对 pattern 是合法的，也没处理跨浏览器的 :user-invalid 兼容性。这些细节不补上，视觉反馈就会和用户预期脱节。 
