@scope 怎样限制选择器范围

我第一次在组件库里用 @scope，是在一个页面同时放了两种卡片之后：普通写法要么把选择器写得很长，要么一个 .card img 把卡片里的缩略图和图表图片一起选中。最终我把问题收窄成一句话：选择器要在这棵 DOM 子树里生效，但不能越过某个嵌套组件。

@scope 正好提供了这个边界。它限制的是选择器能够匹配的 DOM 范围，不是创建一座完全隔离的样式沙箱；继承属性仍可能继续向子树传递。

官方资料：https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/%40scope

@scope 解决的是“样式只在这棵子树生效”

普通后代选择器的作用域是整棵文档树。例如 .article-body img 会命中正文区域里的所有图片，嵌套的 figure、广告位或另一个组件也可能被包含。把选择器改成很长的子代链可以缩小范围，却会把 DOM 结构和样式绑定得过紧。

@scope 把“从哪里开始找”和“找到哪里停止”写成了 CSS 规则本身。最小写法是只给出根：

/* 根元素是 .article-body，内部的 img 都属于这个范围 */
@scope (.article-body) {
  img {
    border-radius: 8px;
  }
}

范围内的裸选择器不会把根选择器的特异性额外叠加到自身上；如果需要明确选中根元素，可以写 :scope，但它会像普通伪类一样增加特异性。这个差别很适合组件库：组件内部规则可以保持轻量，外部覆盖不必先和一串祖先选择器对抗。

先看范围：scope root 和 scope limit

真正需要限制“不要穿过某个嵌套组件”时，使用两个边界：

/* .article-body 是上界，figure 是下界；img 只在两者之间匹配 */
@scope (.article-body) to (figure) {
  img {
    outline: 2px solid steelblue;
  }
}

.article-body 是 scope root，上界本身包含在范围内；figure 是 scope limit，下界默认不包含，所以嵌套在 figure 里的图片不会命中这条规则。这个形态常被称为 donut scope：从一个根开始，但绕开某类内部区域。

如果不需要下界，就省略 to (...)。如果要改变边界的包含关系，可以在根或限制选择器外再加通用子选择器，例如 to (figure > *) 会让限制元素本身不再作为终点，而是把它的直接子元素作为终点。实际项目里我更建议先用最直观的根和下界，只有确实需要调整包含关系时再引入这种写法。

我会怎样在项目里选择 @scope

我现在会把三个方案放在同一张决策表里，而不是看到新语法就全部替换。

我的选择规则很简单：如果组件边界是产品结构的一部分，就优先用 @scope；如果只是一个不会嵌套的页面小片段，普通选择器往往更容易维护；如果目标环境无法确认支持情况，就保留一条同语义的类名前缀写法。

/* 兼容方案：用稳定的组件类名前缀表达相同边界 */
.article-body > img {
  border-radius: 8px;
}

/* 新环境：把组件根和禁止穿透的边界直接写进 CSS */
@scope (.article-body) to (figure) {
  img {
    border-radius: 8px;
  }
}

这两段不要在同一环境里盲目叠加出不同视觉结果；应把兼容写法作为降级路径，并结合项目支持矩阵决定加载方式。更重要的是，@scope 不会阻止继承，所以全局的 color、font-family 等仍可能沿 DOM 继续传递，不能把它当成 Shadow DOM 的替代品。

嵌套主题为什么要看 scoping proximity

主题卡片嵌套时，同一个段落可能同时落入外层浅色主题、内层深色主题和更内层浅色主题。普通类名规则常常依赖源码先后顺序，后写的规则不一定就是更符合组件意图的规则。放进不同的 @scope 后，CSS 级联会多一个判断：哪个 scope root 离目标元素更近，哪个范围就更有优先感。

/* 两个范围都能覆盖 p，但嵌套更近的主题具有更近的 scope root */
@scope (.light-theme) {
  p {
    color: #17202a;
  }
}

@scope (.dark-theme) {
  p {
    color: #f7f9f9;
  }
}

这里的“更近”不是让 @scope 无条件压过所有规则。重要性、层叠层和特异性等更高优先级条件仍会参与决策；scoping proximity 主要解决多个范围都适用、而其他条件相当时的选择问题。使用它时，主题根最好保持语义清晰，不要把过于宽泛的 div 当成范围根。

兼容旧环境时保留一条退路

采用前我会确认三件事：目标浏览器是否支持 @scope；构建链是否会原样保留该 at-rule；组件是否真的需要一个可表达的下界。如果任一项不确定，先使用稳定的根类名和较低特异性选择器，并把未来迁移点写在组件样式说明里。

还要特别区分“限制匹配范围”和“隔离继承”：前者是 @scope 的职责，后者需要 Shadow DOM、明确的继承重置或组件设计共同完成。只要把这条边界讲清楚，@scope 就很适合用来降低长选择器的维护压力。

常见问题

@scope 会自动阻止所有继承吗？

不会。它限制选择器匹配的子树，但继承属性仍可能穿过 scope limit。需要真正隔离时，要采用组件封装或显式处理继承。

为什么不直接给每个组件都加唯一前缀？

前缀仍然是可靠的兼容方案，但它把边界依赖在命名约定上。组件存在嵌套主题、需要明确下界或希望降低选择器长度时，@scope 能把边界写得更接近结构意图。

总结：用根选择器表达“从哪里开始”，用 scope limit 表达“到哪里停止”，用 scoping proximity 处理嵌套主题冲突；不要把 @scope 误认为完全隔离的样式沙箱。这样选择范围才不会和页面 DOM 结构一起失控。