^=、$=、= 仅支持字面量前缀/后缀/子串匹配，不支持正则语法；如^[0-9]无效，|非“或”逻辑，= 区分大小写且无单词边界，复杂匹配应交由 JS 处理。
attribute selector 中 ^=、$=、*= 的实际匹配边界
这三个符号不是正则，是 CSS 属性选择器的“子串定位操作符”，但很多人误以为它们支持完整正则语法，结果写 [data-id^="\d+"] 这种写法——直接失效。
它们只做**字符串前缀/后缀/包含匹配**，不解析转义、不支持量词、不认 \d 或 + 等正则元字符：
-
^=：严格从属性值开头匹配字面量（如[class^="btn-"]匹配class="btn-primary"，不匹配" my-btn"） -
$=：严格匹配结尾字面量（[href$=".pdf"]可以，但[src$="[0-9].jpg"]不行） -
*=：只要中间连续出现该子串就匹配（[alt*="error"]匹配"Validation error occurred"，也匹配"no-error"）
为什么 [attr^="a|b"] 不等于正则的 ^(a|b)
CSS 选择器里没有分组、或逻辑、锚点概念。^= 后面只能跟一个静态字符串，| 在这里就是普通字符，不是“或”。
想实现“以 a 或 b 开头”，只能拆成两个选择器并联：
立即学习“前端免费学习笔记（深入）”；
[data-type^="a"], [data-type^="b"] { color: red; }
或者换思路：用 JS 动态加 class，再用简单类名选择器。纯 CSS 没有“多前缀 OR 匹配”原生能力。
- 浏览器不会把
^="a|b"当成正则解析，而是当字面量匹配字符串"a|b" - 哪怕写成
^="a\|b"，CSS 解析器也不处理反斜杠转义（除非是 Unicode 转义如\61） - 这种需求在构建时可通过 PostCSS 插件展开，但运行时 CSS 引擎不支持
*= 容易误伤：空格、大小写、HTML 实体都算字符
*= 是最危险的一个——它不区分单词边界，也不忽略空格或大小写。
比如 [title*="edit"] 会意外命中：title="editable content"、title="EDIT mode"、甚至 title="&edit; button"（因为 & 解析后是 & 字符，但 edit 仍连续存在）。
- 它对大小写敏感（
*="Edit"不匹配"edit"），没i标志可加 - 无法跳过 HTML 实体或 Unicode 字符干扰（如
café中的é是单个字符，*="cafe"不匹配） - 若需精确单词匹配，必须靠 JS +
Element.getAttribute()+ 正则，CSS 做不到
真正需要正则匹配时，别硬扛 CSS 选择器
如果业务逻辑依赖动态模式（比如匹配邮箱格式、版本号、路径路由），CSS 属性选择器不是合适工具。
更可靠的做法是让 JS 提前判断并挂 class：
el.classList.toggle("is-external", /^https?:\/\//.test(el.href));
然后用 .is-external 写样式。这样可控、可调试、兼容性无死角。
- CSS 选择器引擎不暴露匹配过程，出错了没法 console.log 查哪段没对上
- 某些旧版 Safari 对
$=处理有 bug（比如末尾带空格的属性值） - 用
:is()或:where()组合多个^=/$=选择器虽可行，但可读性和维护性迅速下降
真要靠属性值驱动样式，优先保证属性值本身结构规整（比如统一用 kebab-case、避免空格和特殊符号），比在选择器里搞花活靠谱得多。
