先记住这个答案
不能互相替代。@scope 是 CSS 层面的选择器作用域，它让你的选择器只在指定的 DOM 子树里匹配，但外部样式表里的规则如果优先级够高，照样能覆盖 @scope 里的声明。Shadow DOM 是 DOM 层面的封装边界，外部选择器根本无法匹配 Shadow 内部的元素，内部的样式也出不去。两者解决的是不同层次的问题。
@scope限制选择器匹配范围，不阻挡外部样式- Shadow DOM 建立硬边界，内外样式互不影响
@scope限制范围，Shadow DOM 隔离树- 两者可以在 Shadow DOM 内部配合使用
外部样式能不能穿透进去
这是区分两者最直观的方式。同一段 HTML，分别用 @scope 和 Shadow DOM 包裹，再从外部试图覆盖内部样式。
@scope 挡不住外部高优先级规则HTML<style>
/* 外部样式 */
.card p { color: red; }
/* @scope 内部样式 */
@scope (.card) {
p { color: blue; }
}
</style>
<div class="card"><p>这段文字是红色</p></div>外部的 .card p 选择器优先级是 (0,1,1)，@scope 里的 p 虽然有作用域邻近度加成，但选择器本身的优先级只有 (0,0,1)，所以外部规则赢了。@scope 只控制选择器的匹配范围，不会自动提升优先级。
如果把这段内容放进 Shadow DOM，外部的 .card p 根本匹配不到 Shadow 里的 <p>，蓝色样式会生效。
各自适合什么场景
@scope 适合在同一个样式上下文内做组件级的命名空间划分。比如一个页面上有 .card 和 .sidebar，用 @scope (.card) 和 @scope (.sidebar) 可以让两组样式互不干扰，不用手动加 BEM 前缀。但如果全局有个 p { margin: 0 } 的 reset 规则，它照样会影响 @scope 内部的 <p>。
Shadow DOM 适合需要完全封装的场景，典型的是可复用的 Web Components。组件发布到 npm 后，使用者页面上的任何全局样式都不会意外改变组件内部的样式。代价是外部想定制组件样式只能通过 CSS 自定义属性或 ::part() 伪元素，灵活性受限。
@scopeCSS/* 在 Shadow DOM 的 <style> 里 */
@scope (:host) to (.slot-area) {
p { color: blue; }
}Shadow DOM 已经隔绝了外部干扰，内部再用 @scope 可以进一步划分区域。比如组件内部有个 slot 区域不想被组件自己的样式影响，用 to(.slot-area) 排除它。
容易答错的地方
- 以为
@scope也能阻止外部样式 @scope只限制自己的选择器往下匹配到哪里，不会阻挡外部规则穿透进来。外部只要选择器写得够具体，照样能覆盖@scope内部的声明。想要真正的样式隔离，只能用 Shadow DOM。- 以为 Shadow DOM 里不能用全局样式
- CSS 自定义属性（
--color-primary之类）可以穿透 Shadow 边界，可继承的属性（color、font-family）也会继承进去。所以 Shadow DOM 不是完全的「样式黑洞」，而是挡住了选择器匹配，保留了继承通道。
面试官还会怎么问？
Vue 的 scoped 和 @scope 是一回事吗？
不是。Vue 的 scoped 是在编译时给每个元素加上随机的 data-v-xxx 属性，然后用属性选择器限制匹配范围，本质是选择器改写。CSS 原生的 @scope 是浏览器层面的作用域机制，不需要编译、不改动 HTML。但两者的隔离程度类似，都挡不住外部高优先级规则。
@scope 会影响优先级计算吗？
@scope 本身不增加选择器的优先级权重。但规范引入了「作用域邻近度」(scope proximity) 概念：当两条规则优先级相同时，离作用域根更近的规则胜出。这只在优先级打平时才起作用。
什么场景下两者需要同时用？
设计系统里的复杂组件。Shadow DOM 保证组件和页面互不干扰，组件内部再用 @scope 划分 header、body、footer 等子区域的样式命名空间，避免组件内部的选择器冲突。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。