Sass 的 @use 和 @import 无法隔离第三方 CSS 规则，仅能封装变量和混合宏；真正样式隔离需依赖 CSS Modules、Shadow DOM 或 iframe 等运行时/构建层方案。
用 @import 直接导入第三方 CSS 会污染全局作用域
第三方库（比如 normalize.css 或 bootstrap.min.css）自带大量全局选择器，一旦用 @import 写进主 Sass 文件，它们的样式就会无差别生效，和你自己的 .btn、h1 等规则混在一起，后期覆盖成本极高。
实操建议：
- 不要在
main.scss顶层直接@import "node_modules/bootstrap/dist/css/bootstrap.min.css" - 改用
@use（Dart Sass 1.23+）或@import+prefix配合命名空间（旧版）隔离变量/混合宏，但注意：CSS 规则本身仍会全局注入 - 真正要“隔离样式规则”，得靠 CSS Scope —— 把第三方类名包裹进一个自定义类容器里，例如：
.my-app { @import "bootstrap"; }，但这仅对非:root、非伪类等简单规则有效，且会破坏第三方库的 JS 绑定逻辑（如 Bootstrap 的data-bs-toggle依赖原生类名）
Sass 的 @use 无法封装第三方 CSS 规则，只能封装其 Sass 变量和混合宏
像 Bootstrap 5 提供了 Sass 源码（scss/ 目录），你可以 @use "bootstrap/scss/functions" 来复用它的颜色函数，但只要你 @include bootstrap/scss/components/buttons 或 @import "bootstrap/scss/bootstrap"，生成的 CSS 就仍是全局的。
关键区别：
立即学习“前端免费学习笔记（深入）”；
-
@use "bootstrap/scss/mixins"→ 安全，只加载 Sass 逻辑，不产出 CSS -
@import "bootstrap/scss/buttons"→ 危险，立即输出按钮相关 CSS 到最终文件 -
@use "bootstrap/scss/bootstrap" as bs→ 语法合法，但bs命名空间对已编译的 CSS 规则无效
真正隔离第三方样式的可行路径：CSS Modules 或 Shadow DOM
Sass 层面做不到“样式作用域”，这是 CSS 本身的限制。想让 bootstrap 的 .card 不影响项目其他 .card，必须跳出 Sass 思维：
- 前端框架用户（React/Vue）：用 CSS Modules 或
<style scoped>，让构建工具自动加属性选择器前缀，第三方 CSS 需先转成模块再引入（例如通过postcss-modules处理） - 纯静态项目：用
iframe加载第三方组件（重，但彻底隔离） - 现代浏览器环境：把第三方 UI 封装进 Shadow DOM，外部样式无法穿透，内部样式也不会漏出 —— 这才是语义上真正的“隔离”
- 别碰
!important覆盖，它只会让后续维护者想删库跑路
如果必须用 Sass 管理，优先选“按需导入 + 显式重置”
与其幻想隔离，不如控制影响范围。Bootstrap、Element Plus 等库都提供可拆分的 Sass 文件，利用这点最小化注入：
- 只
@import "bootstrap/scss/forms"，别@import "bootstrap/scss/bootstrap" - 在导入前用
$enable-rounded: false等开关关闭不需要的特性，减少冗余 CSS - 导入后立刻写重置规则，例如：
.my-form { @import "bootstrap/scss/forms"; } .my-form * { box-sizing: border-box; }，至少把影响框死在局部结构内 - 检查最终 CSS 输出体积 —— Webpack 的
stats: "verbose"或 Vite 的build.report能看出哪些第三方样式被打了进来
第三方样式从来不是“导入即用”的问题，而是“谁在什么时候、以什么粒度、承担什么副作用”的权衡。Sass 的 @use 和 @import 只负责代码组织，不负责样式沙箱。真要隔离，得靠构建链路或运行时机制，而不是指望预处理器替你兜底。
