应使用a[target="_blank"]或a[rel="external"]等语义化HTML属性选择器替代[href^="http"]，因其能精准识别真实外链、规避协议变体、大小写、子串误判及动态路由干扰，符合安全规范且无歧义。
为什么 [href^="http"] 总是漏匹配或误匹配
这个选择器只认严格以小写 http:// 开头的字符串，对其他常见外链形式完全失效：https://、//cdn.example.com、HTTP://OLD.COM 全部不匹配；而像 /page?ref=http%3A%2F%2Ftest.com 这种内链含 http 子串的，反而会被错误选中。
用多个 href 前缀组合仍不可靠
即使显式写出 a[href^="http://"], a[href^="https://"], a[href^="//"]，也解决不了语义歧义问题：
-
//fonts.googleapis.com是静态资源，不该和跳转外链同等待遇 -
//assets.myapp.com可能是同域 CDN，算不算“外部”取决于业务定义，CSS 无法判断 - 协议相对链接（
//）在页面协议切换时行为不一致，且无法区分是否跨源
真正可行的做法：让 HTML 显式表达意图
CSS 不该承担 URL 解析或同源判断的职责。可靠方案必须把识别逻辑前移到 HTML 层：
- 所有需新开页的外链，本就应带
target="_blank"和rel="noopener"—— 这是安全规范强制要求的，对应 CSS 写成a[target="_blank"]（注意引号，a[target=_blank]在部分浏览器中无效） - 更推荐后端或构建工具自动为外链注入
rel="external"，CSS 用a[rel="external"]精准捕获 - 内链也可主动加
class="internal"，比“排除所有外链”更可控、无歧义、可测试
别忽略重定向和动态路由带来的干扰
用户点击的链接可能是短链、跳转页或前端路由（如 /go?url=https://xxx），真实目标在 JS 执行后才确定。CSS 渲染时既看不到重定向，也不知道当前域名，更无法执行字符串比对逻辑。任何基于 href 字符串的静态匹配，本质都是在模拟一个它根本无法完成的行为。
立即学习“前端免费学习笔记（深入）”；
