一个组件库与页面样式打架的现场
假设页面里有一个商品卡片组件，组件库的 CSS 里写了 .card a { color: #1a73e8 }，页面自己的样式表里又写了 .card a { color: #d93025 }。两条规则的选择器完全相同，特异性都是 (0,1,1)。页面样式表在组件库之后加载，于是出现顺序更靠后的页面规则胜出，卡片里的链接全部变成红色。页面作者想恢复组件库的蓝色，只能加 !important，或者把选择器写成 .page .card a 来抬高特异性。
这类问题在组件库与页面样式共存时反复出现。直觉上的解法是“把选择器写得更具体”，但具体到什么程度没有上限：页面可能又加一层容器，组件库又加一层变体类，双方不断加码。另一种直觉是“让组件库的规则后加载”，可加载顺序由打包工具和 HTML 结构决定，页面作者往往控制不了。
@scope 提供了一条不同的路径。它不改变选择器的特异性，而是给规则附加“作用域根”这一层信息，并在层叠中插入一个新步骤——作用域邻近性（scoping proximity）。当两条规则的来源、层、重要性和特异性都相同时，谁的声明离它自己的作用域根更近，谁就胜出。
@scope 限定的到底是什么
@scope 是一个 CSS at-rule，用来把一组样式规则限制在 DOM 的某个子树内。它有两种写法。独立块形式带一个前奏：
@scope (.card) to (.card__content) {
img { border: 1px solid #ccc; }
}.card 是作用域根，决定匹配范围的上界；.card__content 是作用域限制，决定下界。上界包含、下界排除，这种带上下界的范围通常称为 donut scope（甜甜圈作用域）。只有位于 .card 内部、但不在 .card__content 内部的 img 会被选中。
另一种是内联形式，把 @scope 放进 HTML 的 <style> 元素里，省略前奏，规则自动以 <style> 的父元素为作用域根：
<section class="card">
<style>
@scope {
img { border: 1px solid #ccc; }
}
</style>
<!-- ... -->
</section>这里需要区分两件事：@scope 限制的是选择器的匹配范围，不是样式的继承范围。color、font-family 这类可继承属性仍然会越过作用域下界传给子元素。如果 donut 的“洞”里放了一个 <span>，它不会被 @scope 内的规则直接选中，但仍会继承外层的 color。
作用域根选择器本身不参与内部规则的特异性计算。@scope (#sidebar) { img { ... } } 里的 img，特异性仍然是 (0,0,1)，不会因为根是 ID 选择器而变成 (1,0,1)。这是 @scope 与“写更具体的选择器”最根本的区别。
:scope 边界与 donut 作用域
在 @scope 块内部，:scope 伪类代表匹配到的作用域根元素。要给根元素本身加样式，直接写 :scope：
@scope (.card) {
:scope { border: 1px solid #ddd; }
img { border: 1px solid #ccc; }
}:scope 的特异性与普通伪类相同，是 (0,1,0)。所以 :scope img 的特异性是 (0,1,0) + (0,0,1) = (0,1,1)，而裸 img 仍是 (0,0,1)。两者虽然都选中根内的图片，但特异性不同，在与其他规则比较时结果可能不同。
作用域限制里也可以用 :scope 表达与根的特定关系。例如只把根的直接子元素 .content 当作下界：
@scope (.media-object) to (:scope > .content) {
/* ... */
}这里 .content 只有在它是作用域根的直接子元素时才会成为限制。如果 .content 出现在更深层，它不会截断作用域。
还有一个容易踩的边界：作用域内的选择器不能“逃出”子树。:scope + p 这类写法试图选中根之外的兄弟元素，在 @scope 内不成立。作用域根是匹配的起点，不是跳板。
作用域邻近性在层叠中的位置
层叠算法按固定顺序比较声明。资料给出的顺序是：先按来源和重要性排序（用户代理普通、用户普通、作者普通、CSS 动画、作者 !important、用户 !important、用户代理 !important），同一来源内再按层排序，然后是特异性，最后是出现顺序。@scope 在特异性之后、出现顺序之前插入作用域邻近性这一步。
规范对它的描述是：当两条声明来自不同的作用域根时，作用域根与规则主题之间“代际或同级元素跳数”更少的那条胜出。换成可操作的判断方式：从元素出发向上走到各自的作用域根，谁走的层级更少，谁的声明赢。
回到开头的场景。把组件库和页面样式都改成作用域规则：
@scope (.card) {
a { color: #1a73e8; }
}
@scope (.page) {
a { color: #d93025; }
}假设 DOM 是 .page > .card > a。对 a 来说，到 .card 根是 1 跳，到 .page 根是 2 跳。两条规则特异性相同，作用域邻近性判定 .card 更近，于是组件库的蓝色胜出，页面样式不再压过组件内部样式。页面作者不需要加 !important，也不需要把选择器写成 .page .card a。
这正是“内层规则覆盖外层同名选择器”的机制来源：不是内层特异性更高，而是内层作用域根离元素更近。
flowchart TD
A[元素 a] --> B{收集匹配声明}
B --> C[组件库规则: @scope .card 内 a]
B --> D[页面规则: @scope .page 内 a]
C --> E[来源与层相同]
D --> E
E --> F[特异性相同 0,1,1]
F --> G[作用域邻近性比较]
G --> H[到 .card 1 跳]
G --> I[到 .page 2 跳]
H --> J[组件库声明胜出]
I --> J
与 BEM、@layer 的取舍
BEM 的思路是让类名承担作用域职责：.card__link 只属于卡片组件，页面不会无意中写出同名类。它不依赖浏览器新特性，兼容性最好，但类名与 DOM 结构、组件层级强绑定，组件重构时类名要跟着改。跨组件复用时，页面想覆盖 .card__link 的颜色，仍然要靠更高特异性或 !important。
@layer 解决的是另一个维度的问题：它按层声明优先级，让低层规则整体让位于高层规则，与选择器特异性无关。页面可以把组件库放进低层、自己的覆盖样式放进高层，覆盖关系稳定且可预测。但 @layer 是全局的，它不区分“这个 .card 和那个 .card”，同一层内同名规则仍按特异性和出现顺序比较。
@scope 补的是“同一层、同一特异性下按位置决定胜负”这一块。三者可以组合：用 @layer 划分组件库与页面的优先级，用 @scope 在层内表达组件边界，用 BEM 或语义类名维持可读性。
| 方案 | 决定胜负的维度 | 是否改变特异性 | 作用范围 | 主要成本 |
|---|---|---|---|---|
| 提高选择器特异性 | 特异性 | 是 | 单条规则 | 特异性军备竞赛，难覆盖 |
| BEM 类名 | 类名约定 | 否 | 组件命名空间 | 类名与结构耦合，重构成本 |
| @layer | 层顺序 | 否 | 全局层 | 不区分同层内不同组件实例 |
| @scope | 作用域邻近性 | 否 | DOM 子树 | 依赖浏览器支持，继承不受限 |
生产中的观察信号与失败模式
作用域邻近性只在来源、层、重要性和特异性都相同时才起作用。如果页面规则写成了 .page .card a，特异性是 (0,2,1)，高于组件库的 (0,1,1)，那么特异性这一步就已经分出胜负，根本轮不到作用域邻近性。诊断时先看 DevTools 的 Computed 面板，它会列出被覆盖的声明以及每一条的判定依据；如果覆盖原因显示为 specificity 而非 scope proximity，说明问题出在选择器写法，不是作用域。
另一个失败模式是作用域根选错。如果组件库把根写成 .card，但页面里卡片被包在 .card-wrapper > .card 里，而页面样式的作用域根恰好是 .card-wrapper，那么对卡片内的链接来说，到 .card 是 1 跳，到 .card-wrapper 是 2 跳，组件库仍然胜出。但如果页面样式直接以 .card 为根，两者跳数相同，作用域邻近性无法分出胜负，会退回到出现顺序，后加载的页面样式又赢了。
donut 作用域的上下界也要留意。上界包含、下界排除，如果下界选择器写得太宽，比如 to (.card) 把根自己也排除掉，作用域内可能什么都选不中。
可观测信号方面，可以在 DevTools 里选中元素，查看 Styles 面板中每条规则的来源和 scope 标注；对于复杂页面，用 CSSScopeRule 接口在 JavaScript 里读取 start 和 end 属性，确认作用域边界是否符合预期。
适用边界与版本前提
@scope 是 CSS Cascading and Inheritance Level 6 引入的能力，属于较新的特性。资料显示其浏览器支持状态为 Baseline 2026，2026 年 3 月起在最新设备与浏览器版本上可用，旧版本可能不支持。在需要覆盖旧浏览器的项目里，直接依赖 @scope 决定样式胜负会导致降级后样式错乱。
渐进增强的做法是：把 @scope 当作“让覆盖关系更稳定”的优化，而不是唯一保障。基础样式仍用低特异性选择器或 BEM 类名保证可读性，@layer 保证层间优先级，@scope 在支持的浏览器上进一步稳定同层同特异性下的胜负。这样即使 @scope 不被识别，页面也不会完全失去样式。
还需要注意，@scope 不提供样式隔离。Shadow DOM 会真正隔离选择器和继承边界，@scope 只限制选择器匹配范围，继承仍然穿透。如果需求是彻底隔离组件内部样式，Shadow DOM 更合适；如果需求只是让组件样式不被页面同名规则意外覆盖，@scope 的作用域邻近性更轻量。
最后，作用域邻近性比较的是“跳数”，不是“特异性”。当两个作用域根到元素的跳数相同时，它不会给出额外权重，胜负仍由出现顺序决定。设计组件库时，让组件根尽量靠近被样式化的元素，比堆叠选择器更符合 @scope 的判定逻辑。