html input 伪类需严格匹配触发条件：:focus要求可聚焦且非disabled；:disabled/:read-only依赖显式属性；:valid/:invalid需交互后生效；:placeholder-shown不适用于type="number"；:checked仅限checkbox/radio；:required与:invalid样式易冲突；移动端:focus不可靠，须js补全；无障碍必须用aria属性。
HTML input 标签本身不带状态切换逻辑，所有视觉反馈都依赖属性 + 伪类 + JS 协同；单独写 :hover 或 :focus 很容易失效，关键在理解每个伪类的触发条件和限制边界。
哪些伪类能直接用，哪些必须配属性？
伪类不是“自动生效”的开关，它只响应特定 DOM 状态或用户行为：
-
:focus：仅当元素获得焦点（tab 键或鼠标点击）时匹配，但disabled元素永远不会触发，readonly可以触发 -
:disabled和:read-only：必须显式设置disabled或readonly属性才匹配，JS 动态设el.disabled = true才会更新样式 -
:valid/:invalid：依赖 HTML5 验证属性（如required、type="email"、minlength），且需用户至少交互过一次（初始加载时多数浏览器视为:valid） -
:placeholder-shown：仅当 placeholder 文本可见时匹配，输入内容后立即失效；不能用于type="number"等部分类型（iOS Safari 不支持）
:checked 只对 checkbox/radio 有效，别误用在 select 或 option 上
:checked 是严格限定类型的伪类，它不会匹配 <select></select> 的选中项，也不会作用于 <option></option> 元素 —— 后者靠的是 selected 属性，而该属性无法用 CSS 伪类捕获。
常见错误是这样写：
option:checked { background: #007BFF; } /* 不生效 */
正确做法只有两种：
- 用 JS 监听
change事件，动态加 class 控制<option></option>父容器（如<select></select>）样式 - 放弃原生
<select></select>，用自定义下拉组件（div+ul+aria-expanded）实现完全可控的选中态
:required 和 :optional 的样式优先级容易被 :invalid 覆盖
:required 本身只是标记“这个字段带 required 属性”，它不判断值是否为空；但一旦用户清空必填字段，:invalid 就会同时匹配，此时若两者样式冲突，:invalid 通常胜出（因为更具体）。
比如你写了：
input:required { border-left: 3px solid #007BFF; }
input:invalid { border-color: #dc3545; }
结果是：空的必填框只显示红色边框，左侧蓝条被覆盖。解决方法是提高 specificity 或改用组合：
- 用
input:required:not(:valid)精确控制“必填但无效”状态 - 避免对同一属性（如
border-color）在多个伪类里重复设值 - 把提示性样式（如星号、图标）放在
::before或 label 上，不依赖边框等易被覆盖的属性
移动端 focus 行为不可靠，别只靠 :focus 做验证反馈
iOS Safari 中，input 在软键盘弹出后常不触发 :focus，安卓 WebView 也存在类似问题；:focus-within 在部分旧版安卓浏览器中完全不支持。
这意味着仅靠 CSS 伪类做失焦校验（如 input:focus:not(:valid)）在移动端大概率失效。实际方案要分层：
- 用
blur事件监听 +reportValidity()主动触发验证 - 对关键字段（如手机号、邮箱），在
input事件中做节流实时校验（非全量，只检查格式） - 把
:focus样式当作“辅助高亮”，而非唯一交互依据；核心反馈逻辑下沉到 JS
最易被忽略的一点：伪类样式再漂亮，也无法替代 aria-invalid 和 aria-describedby —— 没有它们，屏幕阅读器用户根本不知道哪里错了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
