[type="email"]仅匹配html中显式声明的邮箱输入框，不触发验证状态；需配合required、pattern等校验属性或用户失焦后，:invalid才生效。
用 [type="email"] 匹配邮箱输入框但常失效？先确认验证属性是否就位
单纯写 input[type="email"] 只能选中 HTML 中明确写了 type="email" 的 input 元素，但它本身不触发 :invalid 或 :valid 状态。很多开发者误以为加了这个选择器就能响应格式错误，结果样式没变——因为浏览器还没执行验证。
- 必须同时存在
required、pattern或用户已失焦（blur），:invalid才会生效 -
type="email"仅影响输入类型提示和软键盘，不等于“自动校验” - 动态插入的元素（如 Angular 的
ngModel绑定）可能延迟渲染type属性，需等 DOM 稳定后再查询
为什么 input[disabled] 有时匹配不到？检查属性是否存在而非布尔值
CSS 属性选择器匹配的是 HTML 属性（attribute），不是 DOM 属性（property）。disabled 在 HTML 中是布尔属性，写法只有两种：disabled 或 disabled=""；但 JS 设置 el.disabled = true 不会自动同步到 HTML attribute，导致 input[disabled] 失效。
- 手动设置时用
el.setAttribute('disabled', '')，而非赋值el.disabled = true - 框架（如 React/Vue）通常通过指令或绑定控制，它们内部处理方式不同，需查文档确认是否反射为 HTML attribute
- 调试技巧：在 DevTools 中右键元素 → “Edit as HTML”，看
disabled是否真实存在于标签内
[class~="btn-primary"] 和 .btn-primary 有什么区别？别在 class 多值时搞混
[class~="btn-primary"] 是单词匹配，等价于“class 中包含独立单词 btn-primary”，而 .btn-primary 是类选择器，只要 class 列表里有该词就命中。二者在多数场景效果一致，但边界情况差异明显：
- 当 class 是
class="btn btn-primary active"时，两者都匹配 - 当 class 是
class="btn-primary-extra"时，[class~="btn-primary"]不匹配（因为不是独立单词），但.btn-primary-extra会匹配 - 若 class 值含空格分隔的多个词，且你只关心其中某个语义词（如
form-control invalid中的invalid），用[class~="invalid"]更安全
用 [href^="https"] 控制外部链接样式？注意协议拼写和大小写
属性前缀匹配（^=）对大小写敏感，https 和 HTTPS 是不同字符串。实际页面中，URL 协议部分几乎总是小写，但某些服务端重写或前端拼接可能引入大写，导致选择器漏匹配。
- 稳妥做法是统一转小写再比较，CSS 无法做转换，所以得靠 JS 预处理或后端规范输出
- 更健壮的替代方案：用
a[href*="://"]模糊匹配协议分隔符，再配合:not([href^="http://"])排除 http - 注意：伪类如
:link和:visited不能与属性选择器链式组合（如a:link[href^="https"]无效），浏览器会忽略整条规则
data-* 属性，只要没显式写进 HTML 源码，[data-loaded] 就不会生效——这时候得换用类名或自定义伪类（如 :has() 配合现代浏览器支持）。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
