[href^="value"]是唯一精准匹配URL开头的选择器，但易因href值含空格、大小写不符、动态渲染延迟、误用于布尔属性或协议省略等导致失效。
[href^="value"] 是唯一能精准匹配“以某 URL 开头”的链接的选择器，但必须注意值是否带协议、大小写、空格和动态渲染时机。
为什么 [href^="https"] 有时不生效
这个选择器对字符串起始位置零容忍，常见失效原因有：
- HTML 中 href 值实际是
href=" https://example.com"（开头带空格），[href^="https"]就完全不匹配 - JavaScript 动态插入的链接，若在 DOM 渲染后才写入
href，CSS 规则可能已计算完毕，样式不会回溯应用 - 写了
[href^="HTTPS"]却去匹配href="https://"——它严格区分大小写 - 误用在布尔属性上，比如
[disabled^=""]，disabled没有属性值，^=语法根本不适用
[href^="http"] 和 [href^="https"] 的实际覆盖范围
这两个写法看似接近，但语义和匹配结果差异明显：
-
[href^="http"]会同时命中http://和https://链接，适合统一处理所有外部 HTTP 协议链接 -
[href^="https"]只匹配以https开头的值，比如https://api.example.com，但不匹配https:（缺双斜杠）或HTTPS://（大小写不符） - 若要兼容协议省略写法（如
//cdn.example.com），得额外加一条[href^="//"]，不能靠^="http"覆盖
匹配站内路径时，[href^="/"] 的边界要注意
写成 [href^="/"] 看似能选中所有相对根路径链接，但容易误伤：
立即学习“前端免费学习笔记（深入）”；
- 它会匹配
href="/login"，但也匹配href="/static/js/app.js"、甚至href="/?ref=https://evil.com"（URL 参数里带/） - 如果只想匹配导航类路径（如
/about、/products/123），更稳妥的是加限定：比如[href^="/"][href!="/"]排除纯/，或配合 JS 过滤 - 注意服务端渲染时，
href可能被注入 base URL（如href="https://site.com/about"），此时[href^="/"]完全失效，得改用[href*="://"]或协议判断逻辑
真正难的不是写出 [href^="..."]，而是确认 HTML 输出的 href 值是否干净、是否可控、是否在 CSS 计算时机前就已存在——这些细节往往比语法本身更决定成败。
