属性选择器[attr="value"]要求属性值严格全等且区分大小写，如[type="submit"]仅匹配显式写出该值的元素，不匹配隐式默认值或子串。
属性选择器的等号匹配规则怎么写
属性值必须完全一致才匹配，不是“包含”或“开头”。比如 [type="submit"] 只选 <button type="submit"></button>，不选 <button type="submit-primary"></button> 或 <input type="submit">（注意：HTML 中 button 默认 type="submit" 是浏览器行为，但属性未显式写出时不会被 [type="submit"] 匹配）。
常见错误是误以为 [class="btn"] 能选中 class="btn large primary" —— 实际不能，因为值不相等。此时该用 [class~="btn"]（空格分隔的单词匹配）。
-
[attr="value"]：严格全等，区分大小写（HTML 属性值不区分大小写，但 CSS 选择器区分） -
[attr~="value"]：匹配空格分隔列表中的独立单词，适合class、rel -
[attr*="val"]：子串匹配，如[href*="https://"] -
[attr^="val"]：开头匹配，常用于[data-id^="user-"] -
[attr$=".png"]：结尾匹配，适合资源类型筛选
data-* 属性选择器为什么有时不生效
根本原因就两个：属性没正确渲染到 DOM，或选择器写了大小写/连字符错误。浏览器把 data-user-id 当作一个整体，不能写成 [dataUserId] 或 [data-user_id]。
React/Vue 等框架里，如果 data- 属性是动态计算的，且值为 null、undefined 或空字符串，DOM 上根本不会出现该属性 —— 这时选择器自然无效。
立即学习“前端免费学习笔记（深入）”；
- 检查元素面板，确认属性真实存在且拼写完全一致（含连字符、大小写）
-
data-属性值若含空格或特殊字符，要用引号包裹：[data-tip="need help?"] - 服务端渲染（SSR）中，若属性在 hydration 前未同步，可能造成闪动或初始不匹配
属性选择器性能差吗？哪些情况要警惕
单个属性选择器（如 [disabled]）性能几乎无感；但组合嵌套过深或配合通配符时，会显著拖慢重排重绘。尤其是 [class*="foo"] 这类子串匹配，在大 DOM 树中需逐字符扫描。
更隐蔽的问题是：它容易写出「过度具体」的选择器，比如 div.container [data-role="menu"] > ul li a[title]，既难维护，又因层级深+属性过滤，让浏览器放弃快速索引路径。
- 避免在高频更新区域（如列表项）使用
*=、$=等正则式匹配 - 优先用类名代替
[data-xxx]做样式控制，除非语义确实需要数据驱动 - 不要用
[style]匹配内联样式——它不稳定，且 style 属性可能被 JS 动态增删
布尔属性（如 disabled、checked）怎么写选择器
HTML 布尔属性只要存在即为真，值写不写、写什么都无关紧要。所以 [disabled] 就够了，不用写 [disabled="disabled"] 或 [disabled="true"] —— 后者反而会漏掉 <button disabled></button> 这种无值写法。
但注意：JS 设置 el.disabled = false 会移除 disabled 属性，而 el.setAttribute('disabled', 'false') 会让属性还在，只是值是字符串 "false"，此时 [disabled] 仍能匹配，但语义已错乱。
-
[checked]匹配所有显式带checked属性的<input type="checkbox"> -
:checked伪类才是反映真实状态的（推荐优先用） - 不要混用
[disabled=""]—— 空字符串值在 HTML 中合法，但选择器行为不可靠
CSS 属性选择器真正难的不是语法，而是判断「这个属性此刻是否稳定存在于 DOM 上」以及「浏览器是否真的按你预期的方式解析它」。多看一眼开发者工具里的实际属性，比查文档更快定位问题。
