第三方组件类名不可硬加项目前缀，因会破坏其内部选择器链（如.el-button.is-disabled失效）、无法匹配动态类名（如.el-select__popper），且库升级时维护成本剧增；应采用语义化wrapper block隔离，并配合:deep()或属性选择器精准覆盖。
第三方组件类名不能硬加项目前缀
直接给 el-button 改成 myapp-el-button 看似隔离，实则破坏第三方库内部选择器链。比如 Element Plus 的 .el-button.is-disabled、.el-select__popper 都是运行时动态生成或强依赖结构的，你一加前缀，这些规则全失效，按钮禁用态、下拉浮层样式立刻丢失。
更麻烦的是：每次库升级，类名结构可能微调（比如从 el-input__inner 变成 el-input__inner-wrapper），你得手动追着改所有“魔改”类名，维护成本指数级上升。
- 不碰第三方组件自身
class属性，只控制它的父容器 - 用 wrapper block 包一层，例如
form-field--date - 所有样式限定在该 block 下作用，靠层级而非暴力前缀
:deep() 和属性选择器怎么选
Vue 项目里想改 .el-input__inner 的内边距，:deep() 是最直接的写法，但要注意它只对当前组件 scoped 样式生效，且会穿透到子组件所有层级——如果子组件也用了 scoped，它照样能命中。
而属性选择器（如 [class*="el-input"] 或 [class^="el-input"]）更轻量、无框架绑定，适合 Webpack/Vite 普通 CSS 或 CSS Modules 场景，但匹配精度低，可能误中其他带类似字符串的类名。
立即学习“前端免费学习笔记（深入）”；
-
:deep(.el-input__inner)→ Vue 单文件组件内首选，明确、可控 -
[class^="el-input"] .el-input__inner→ 兼容性更好，但需确保前缀唯一（el-input不会被其他库复用） - 避免写
:deep(.el-input) :deep(.el-input__inner)，嵌套:deep()无意义，且 Vite 会警告
为什么 CSS 加载顺序比 !important 还关键
很多开发者发现写了 !important 还是盖不过第三方样式，第一反应是“权重不够”，其实大概率是 CSS 文件加载顺序错了。Webpack/Vite 打包后，<link> 标签顺序决定层叠优先级 —— 后加载的 CSS 规则天然覆盖先加载的，哪怕前者带 !important。
比如 Vite 项目中，如果你在 main.ts 里先 import 'element-plus/dist/index.css'，再 import './style/index.css'，那你的样式永远在 Element Plus 后面，!important 也白搭。
- 检查
main.ts或entry文件中的 import 顺序 - 第三方库 CSS 必须在你项目样式之前引入
- Vite 用户可加
css.preprocessorOptions控制全局变量注入时机，但别指望它改加载顺序
BEM wrapper 的 class 命名要带语义，不是随便起
写个 third-party-wrapper 这种泛用名等于没隔离 —— 它不表达业务意图，团队协作时没人知道这个壳管的是日期选择器还是上传组件，后续加修饰符（比如 --loading）也无从下手。
真正有效的命名必须绑定具体场景，比如 user-profile__avatar-uploader 或 order-form__date-range。这样既符合 BEM 块的独立性定义，又让样式作用域天然收敛，连 DevTools 里一眼就能定位问题来源。
- 块名必须体现业务功能，而不是技术来源（不用
el-date-picker-wrapper） - 允许在块名中保留第三方标识，但仅作辅助，如
date-picker--el（修饰符表来源，非主语义） - 避免
ui-xxx、component-xxx这类空洞前缀，它们不提供上下文信息
.form-field--date:deep(...) 就可能在某些状态里完全不生效。 
