CSS类名冲突反复出现，因组件化本身不隔离样式，真正起效的是隔离机制：如CSS Modules通过哈希重命名、scoped用data属性限定、CSS-in-JS运行时生成唯一类名，而非仅靠组件外壳。
为什么 CSS 类名冲突总是反复出现
组件化本身不解决样式覆盖，它只是把问题从全局搬进局部——如果你在组件里还用 .button、.header 这类泛化类名，打包后照样撞车。真正起作用的是「隔离机制」，不是「组件外壳」。Vue 的 <style scoped>、React 中的 CSS Modules 或 styled-components，底层都是靠属性选择器或运行时哈希来切断样式逃逸。
- scoped 样式本质是给元素加 data 属性（如
data-v-f3f2a1b4），再把 CSS 选择器重写成.button[data-v-f3f2a1b4] - CSS Modules 会把
className="btn"编译成类似Button_btn__kx9m2的唯一字符串，JS 和 CSS 同步改名 - 直接写
!important或用 ID 选择器（#my-btn）看似能压住样式，但会让组件失去复用性，也违背 BEM 原则
CSS Modules 在 Webpack 中必须配对启用
光在 JS 里写 import styles from './Button.module.css' 没用，Webpack 必须识别 .module.css 后缀并启用 css-loader 的 modules: true 选项。否则它就当普通 CSS 处理，类名原样输出，毫无隔离效果。
- Webpack 5+ 默认不开启 CSS Modules，需显式配置：
modules: { mode: 'local' } - 若同时用了 Sass，要确保
css-loader在sass-loader之后执行（顺序错会导致模块化失效） - 开发时类名是可读的（如
Button_primary），生产构建默认会压缩成短哈希，但可通过localIdentName自定义格式
Shadow DOM 是真隔离，但兼容性和穿透成本高
attachShadow({ mode: 'closed' }) 创建的 Shadow Root 能彻底阻止外部样式侵入，连 :host 都得显式暴露接口。但它不是“开箱即用”的解决方案：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- Chrome/Firefox/Edge 支持良好，Safari 对
slot和 CSS 变量透传仍有细微差异 - 无法用常规方式获取 shadow 内部节点（
closed模式下shadowRoot返回 null） - 第三方 UI 库（如 Ant Design、Element Plus）基本不基于 Shadow DOM 构建，强行套用会导致主题、动画、表单联动等逻辑断裂
- 若需从外部控制内部样式（比如换肤），得靠 CSS 自定义属性 +
:host声明，不能直接写.inner-button { color: var(--text-primary) }就完事
最易被忽略的：CSS 重置和继承链没清理干净
很多“样式覆盖”其实不是组件间冲突，而是父级样式意外透传。比如全局写了 article p { margin: 0 0 1rem 0 }，结果所有组件里的 <p> 都被影响，哪怕用了 scoped 或 Modules。
立即学习“前端免费学习笔记（深入）”；
- 组件根元素应主动重置继承值：
all: unset太激进，推荐用margin: 0; font: inherit; color: inherit;等关键项 - 避免在组件顶层用通配符：
* { box-sizing: border-box }仍会生效，因为它是浏览器默认样式层之上、组件样式层之下的存在 - 使用
@layer reset（现代 CSS）可明确控制层叠顺序，但目前仅 Chromium 119+ 支持，上线前需检查目标环境
组件化不是银弹，样式隔离的关键不在“拆”，而在“封”——封住入口，封住出口，封住继承路径。漏掉任意一环，都可能在某个深夜的回归测试里突然冒出来一个紫色的按钮。
