[lang|=en] 更安全，因其严格遵循bcp 47规范，要求en为完整主语言标签且后接短横线或结束，故匹配en、en-us等，却不匹配energy或entirely。

[lang|=en] 这个选择器不是“匹配以 en 开头的任意字符串”，而是专为语言标签设计的语义化匹配——它只认标准的 lang 值，比如 en、en-US、en-GB，但不匹配 eng 或 encyclopedia。

为什么 [lang|=en] 比 [lang^=en] 更安全？

语言代码有明确规范（BCP 47），主语言和子标签用短横线分隔。|= 要求右侧值必须是完整单词，且后续要么结束，要么紧跟 -。这意味着：

• [lang|=en] 匹配 <p lang="en"></p>、<div lang="en-US">、<code><span lang="en-GB-x-custom"></span>
• [lang^=en] 会错误匹配 <section lang="energy"></section>、<article lang="entirely"></article>
• [lang~=en] 要求 en 是独立单词（空格分隔），对 en-US 无效

|= 只作用于 lang 属性？

不局限于 lang，但语义上只适合「用短横线分层、首段为根标识」的场景。例如：


CSS婚礼策划服务机构宣传网站模板
CSS婚礼策划服务机构宣传网站模板是一款适合提供婚礼策划和婚庆服务机构宣传网站模板下载。提示：本模板调用到谷歌字体库，可能会出现页面打开比较缓慢。
下载
• 合法：[data-locale|=zh] → 匹配 zh、zh-CN、zh-Hant
• 危险：[class|=btn] → btn-primary 会被匹配，但 btn 本身不是 class 的“语言式根”，容易误伤
• 无效：[id|=main] → id 不按 BCP 47 规则组织，|= 在这里没意义

实际写法中容易漏掉的细节

这个选择器对属性值格式非常敏感：

• 属性值不能带多余空格：lang=" en " 不匹配 [lang|=en]（前后空格破坏了“完整单词”条件）
• 必须是属性原生值，不能靠 JS 动态拼接后生效——浏览器解析 HTML 时就已确定匹配逻辑
• 大小写敏感：[lang|=EN] 不匹配 lang="en-us"；建议统一小写存储

真正要用好 |=，得把属性值当成语言标签来管，而不是普通字符串。一旦脱离 BCP 47 语义，它就从“精准过滤器”退化成“容易踩坑的模糊匹配”。