[href^="https://"]更精准，因[href^="https"]会误匹配https-proxy-config等非URL字符串，且无法区分http/ftp；匹配mailto:/tel:须用^=，大小写敏感时可加i标志确保兼容。
直接用 [href^="value"] 就能匹配以指定字符串开头的 href 值，但必须注意大小写、协议完整性与空格干扰。
为什么 [href^="https"] 有时不生效
它只匹配属性值**字面开头**，不是“协议识别”。常见失效场景包括：
-
href="//example.com"→ 不匹配，因为实际值以//开头，不是https -
href=" HTTPS://example.com "→ 不匹配，首尾空格导致开头是空格，且大写HTTPS与小写https不等 -
href="https://example.com?ref=1"→ 能匹配，查询参数不影响开头判断
[href^="https"] 和 [href^="https://"] 该选哪个
优先用 [href^="https://"]，理由很实际：
-
[href^="https"]会误中href="https-proxy-config"这类非 URL 字符串（只要属性值以https开头就命中） -
[href^="https://"]更精准，排除了伪造前缀的干扰，也自然过滤掉http://和ftp:// - 如果还要覆盖
http://，得另写一条：[href^="http://"]，不能合并成[href^="http"]—— 那样又会误中https
匹配 mailto: 和 tel: 链接的写法
这类协议必须用 ^=，不能用 $= 或 *=，否则完全不生效：
立即学习“前端免费学习笔记（深入）”；
a[href^="mailto:"]::before { content: "✉️"; }a[href^="tel:"]::before { content: "?"; }- 想统一加间距或颜色，可合并选择器：
a[href^="mailto:"], a[href^="tel:"] { margin-inline-start: 4px; } - 别写
[href~="mailto"]——~="是空格分隔单词匹配，对href这种单值属性无效
大小写和 IE 兼容性怎么处理
现代浏览器默认区分大小写，[href^="HTTPS://"] 不会匹配 https://。稳妥做法是：
- 加
i标志：[href^="https://"] i（注意i前必须有空格） -
i在 Chrome、Firefox、Safari、Edge 和 IE9+ 全支持，无需前缀 - IE8 不支持
i，若仍需兼容，只能统一后端/前端输出为小写协议，或改用 JS 补充判断 - 不要依赖浏览器自动标准化 ——
location.href返回的是小写，但 HTML 中写的HTTPS://仍会原样保留在 DOM 的href属性里
真正容易被忽略的是空格和协议拼写一致性：哪怕一个链接里多了一个不可见的全角空格，^= 就彻底失效；而开发时本地测试用 http://，上线却切到 https://，也会让规则突然“失灵”。
