scss覆盖ui组件库样式，应优先用变量重写实现主题定制，局部微调则用::v-deep精准穿透；混用!important与高权重选择器会加剧维护混乱。
直接说结论：SCSS里覆盖UI组件库样式，靠“提权重”是临时止痛药，靠“重写变量”才是根治方案；但两者必须分清场景——改主题色用变量，调某个按钮圆角用 ::v-deep，混着来只会让样式越来越难维护。
为什么 !important 和高权重选择器不是长久之计
浏览器 DevTools 里看到样式被划掉，第一反应常是加 !important 或套三层父类：.page-wrapper .form-container .el-button--primary。这确实能生效，但会带来三个实际问题：
- 每次组件库升级，内部 class 名可能微调（比如
.el-button--primary变成.el-button--filled），你的高权重选择器立刻失效 -
!important会污染后续所有样式调试路径，别人接手时根本不敢动相关 CSS - 构建产物中冗余选择器增多，CSS 文件体积不可控，尤其在多主题项目里容易失控
::v-deep 在 SCSS 中的正确写法与常见翻车点
Vue 的 scoped 样式默认无法穿透子组件，::v-deep 是目前最稳定、工具链支持最好的穿透方式。但它不是万能胶，用错位置就白写：
- 必须写在
<style lang="scss" scoped></style>内部，且::v-deep后要跟一个空格，再写目标类名，例如：::v-deep .el-input__inner—— 缺空格或写成::v-deep(.el-input__inner)都不生效 - 不要嵌套在另一个 class 下再写
::v-deep，比如.my-form ::v-deep .el-input__inner，部分版本 sass-loader 会丢掉前缀，推荐统一写在顶层 - 如果组件用了
teleport（如<el-dialog></el-dialog>），它的 DOM 被移出当前组件作用域，::v-deep失效，得改用全局样式或:global()（Vue 3）
Element UI 的 SCSS 变量覆盖：只改 var.scss，别碰源码
Element UI 所有视觉参数都定义在 node_modules/element-ui/packages/theme-chalk/src/common/var.scss，这才是官方支持的“换肤”路径。关键不是“能不能改”，而是“怎么改才不被覆盖”：
- 新建一个
src/styles/element-variables.scss，先@import "~element-ui/packages/theme-chalk/src/index"，再重写变量，顺序不能反 - 变量名如
$--color-primary、$--border-radius-base，直接赋值即可，不用带!default—— 它们本来就是可覆盖的 - 若使用 Vite，需确保
vite-plugin-style-import或unplugin-vue-components没禁用原始 SCSS 引入；Vue CLI 项目则检查vue.config.js中css.loaderOptions.sass.additionalData是否误注入了重复内容
全局样式 vs 局部覆盖：什么时候该放弃 scoped
不是所有场景都适合 ::v-deep。以下情况建议直接写全局 SCSS：
- 需要覆盖
<el-message></el-message>、<el-notification></el-notification>这类挂载到body的组件 —— 它们不在当前组件 DOM 树内 - 多个页面共用同一套定制规则（如所有
.el-table行高统一为 42px），写在src/assets/styles/element-override.scss并在main.js导入，比每个组件里复制粘贴更可靠 - 团队协作中发现某人总在 scoped 里写
::v-deep+!important，说明局部覆盖已失控，该拉出来统一治理了
真正麻烦的从来不是“怎么覆盖”，而是“谁来维护这些覆盖”。变量覆盖一旦设好，基本一劳永逸；而 ::v-deep 规则散落在几十个组件里，三年后没人记得当初为什么把 .el-select-dropdown 的 z-index 改成 9999。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
