真正“精准”的核心是让CSS选择器权重自然胜出，关键在选择器特异性、作用域控制、加载顺序；优先组合组件库原生类名（如.el-button.my-primary），确保自定义CSS后加载，避免ID和内联样式。
用 !important 不是精准，是放弃精准
直接加 !important 确实能压住组件库样式，但等于把样式权交给了暴力手段——后续任何人想微调都会被卡住，尤其当组件库升级后类名或结构变化，你的 !important 可能突然失效或误伤其他地方。
真正“精准”的核心，是让浏览器的 CSS 选择器权重自然胜出，同时不破坏组件库的可维护性。关键在三点：选择器特异性、作用域控制、加载顺序。
- 优先用组件库暴露的原生类名（如
el-button、ant-btn-primary）组合自定义类，而不是全靠.my-btn单独写 - 确保自定义 CSS 在组件库 CSS 之后加载（检查
<link>顺序或@import位置） - 避免用 ID 或内联 style，它们虽权重高但不可复用、难测试
为什么 .el-button.my-primary 比 .my-primary 更可靠
Vue/React 组件库（如 Element Plus、Ant Design）生成的 DOM 通常带有一组稳定、文档化的基础类名。这些类名不是随机生成的，而是语义化且长期兼容的。单独写一个自定义类，权重只有 10；加上组件库原生类，权重立刻变成 20，天然压制它内部的默认规则。
比如 Element Plus 的按钮默认有 el-button 和 el-button--primary，你写：
立即学习“前端免费学习笔记（深入）”；
.el-button.my-urgent {
background-color: #d32f2f;
border-color: #b71c1c;
}
就比只写 .my-urgent 稳定得多——即使某天组件库把内部实现从 <button> 改成 <span>，只要它还挂 el-button 类，你的样式就还在。
- 不要依赖
data-v-xxx这类 Vue scoped 生成的哈希类，它们每次构建都变，无法用于手动覆盖 - React 中若用 CSS Modules，需通过
:global(.el-button)显式穿透，否则作用域隔离会拦住你 - Tailwind 用户注意：别用
@apply直接复写组件库 class，它不支持跨文件提取，容易漏掉伪类（如:hover）
遇到 Specificity conflict 错误或样式不生效，先查这三件事
浏览器不会报 “Specificity conflict” 这种错误，但开发者工具里常看到样式被划掉、灰显——这就是特异性冲突的实际表现。别急着改代码，先确认底层事实：
- 打开 DevTools → Elements 面板 → 找到目标元素 → 看右边 Styles 面板里，被划掉的那条规则，点右侧的链接跳转到来源文件，确认它是否真来自组件库 CSS（路径含
element-plus或antd） - 检查你写的规则是否被包裹在
@media、:not()或其他条件里，这些会降低实际生效权重 - 如果用了 CSS-in-JS（如 styled-components），确认是否启用了
shouldForwardProp，否则自定义 class 可能根本没渲染到 DOM 上
动态主题下如何保持覆盖逻辑不崩
组件库的主题切换（如暗色模式、多品牌皮肤）往往靠顶层 class（如 dark、theme-ali）配合属性选择器（[data-theme="dark"] .el-button）。此时单靠 .el-button.my-urgent 可能被更高权重的主题规则盖掉。
解法不是堆权重，而是对齐它的作用域层级：
[data-theme="dark"] .el-button.my-urgent {
background-color: #c62828;
}
- 不要复制整个主题 CSS 文件来改，只补缺失的覆盖规则
- 若组件库用 CSS 变量（如
--el-color-primary），优先覆盖变量而非具体属性，一改全改 - 注意 SSR 场景：服务端渲染时
data-theme可能还没注入，需在useEffect或onMounted后再激活相关样式逻辑
最麻烦的不是写多少行 CSS，而是搞清哪一层在控制颜色、边框、阴影——组件库常把它们拆在不同 class 里。盯紧 DevTools 里的 Styles 面板，比读文档更快定位源头。
