CSS @scope 能解决哪些样式隔离问题？

简答

• @scope 让一组规则只在作用域根和可选的 to (...) 边界之间匹配，解决的是选择器匹配范围。
• 它不会阻止继承和自定义属性，也不隔离 DOM、事件或运行时模块。
• @scope 不改变特异性；特异性相同时，作用域根离元素更近的规则胜出。
• 可以与 CSS Modules、@layer 组合，分别负责类名、匹配范围和层叠顺序。

大型页面里常见一个问题：卡片组件里的 .title、后台页面里的 .title 和文章内容里的 .title 互相覆盖。给每个选择器加更长的前缀可以暂时解决，但会让特异性越来越高，组件迁移和覆盖变得困难。

@scope 让一组 CSS 规则只在指定的作用域根和边界内匹配。它解决的是选择器匹配范围，不能把 CSS 变成 JavaScript 模块，也不能自动隔离 DOM、事件或自定义属性。

作用域根限制规则从哪里开始匹配

@scope (.article-card) {
  :scope {
    padding: 1rem;
  }

  .title {
    margin-block: 0 0.5rem;
    color: #1f2937;
  }
}

.title 只匹配 .article-card 作用域内的后代，不会误伤页面其他区域。:scope 表示作用域根本身。作用域根可以是一个选择器列表，规则也可以使用 to (...) 指定嵌套边界：

@scope (.article-card) to (.article-card__footer) {
  .title {
    color: #111827;
  }
}

这里标题规则不会穿过 .article-card__footer 边界继续匹配。边界是选择器匹配范围，不代表元素被移动、隐藏或获得真正的 Shadow DOM 隔离。

@scope 不会阻止继承和自定义属性

作用域内的元素仍然继承父级的 color、字体和自定义属性；全局元素规则也可能参与最终计算。组件如果需要主题变量，仍要设计 token 的来源和覆盖关系；@scope 只是减少了选择器的误匹配。

:root {
  --surface: white;
  --text: #111827;
}

@scope (.panel) {
  .content {
    color: var(--text);
    background: var(--surface);
  }
}

把一个节点移到另一个作用域后，它匹配的规则可能改变；动态增加 class、Portal、Shadow DOM 和 iframe 也有各自边界。不要把作用域名称当作权限或数据隔离机制。

@scope、@layer、CSS Modules 和 Shadow DOM 不是一回事

它们可以组合：CSS Modules 负责类名，@scope 负责局部规则范围，@layer 负责公共样式和业务覆盖的顺序。选择器仍可能与未分层的全局规则竞争，不能只因为用了 @scope 就停止检查最终计算样式。

@scope 不改变选择器的特异性。层叠在比较完特异性之后，还有一步独立的“作用域接近程度”：特异性相同时，作用域根离元素更近的规则胜出。遇到覆盖异常，应同时查看作用域、层、特异性、源顺序和继承，而不是继续增加选择器长度。

迁移组件时要保留语义和降级

可以先把某个组件的规则包进 @scope，再在支持的浏览器中验证作用域边界。旧浏览器不支持时，内部规则不会自动变成另一种隔离机制；要使用 CSS Modules、构建工具转换或保留足够安全的前缀作为降级。

不要把整站所有样式一次性包进一个巨大作用域。作用域根太宽，收益有限；作用域边界与组件 DOM 结构不一致，又会让规则难以理解。每个作用域应对应一个稳定的组件边界，并明确是否允许业务方覆盖。

动态主题、Portal 和浮层通常需要跨越原组件 DOM 的实际挂载位置。浮层规则如果依赖原来的作用域根，传送到外部容器后可能不再匹配；这时应在目标容器设计公共浮层样式，或把作用域和挂载策略一起定义。

验证不只看源码是否“包起来了”

测试应覆盖同名 class 的邻近组件、嵌套作用域、边界元素、主题变量、Portal、Shadow DOM 和旧浏览器降级。开发者工具中检查 computed style 和匹配规则，确认实际元素没有被作用域外的规则意外覆盖。

@scope 的浏览器支持会随版本变化，实验性实现不能直接当成所有目标 WebView 都支持。它适合逐步改善样式架构，但不能代替组件契约、设计 token、可访问交互和真实设备验证。