单独link的css文件仍会污染组件，因css无原生作用域，依赖选择器权重和加载顺序全局生效，需配合命名空间、加载顺序控制及css modules等机制实现真正隔离。
为什么单独 link 的 CSS 文件仍会污染组件？
很多人以为把样式写进独立的 <link rel="stylesheet"> 文件里，就能天然隔离作用域——实际并非如此。CSS 本身没有作用域概念，所有规则按选择器权重和加载顺序全局生效。哪怕你为每个组件建了 button.css、modal.css，只要它们被载入同一页面，.close 这类通用类名依然会互相覆盖。
独立 link 文件 + 命名空间是基础防线
必须配合明确的命名约定，否则拆分只是物理隔离，不是逻辑隔离。重点不是“有没有分开”，而是“会不会撞名”。
- 组件级类名强制加前缀，比如
my-button、my-modal，避免裸用button或modal - 内部子元素采用 BEM 风格：
my-button__icon、my-button--large - 禁止在独立 CSS 文件中写全局重置（如
*, body, h1），这类规则应统一收口到主样式入口 - 如果使用构建工具（如 Webpack），确保
mini-css-extract-plugin正确提取，而不是把多个 CSS 合并成一个后又失去拆分意义
link 加载顺序错乱会导致样式覆盖不可控
浏览器按 HTML 中 <link> 出现顺序解析 CSS，后加载的同权重规则会覆盖先加载的。若组件 A 的 a.css 在 index.html 底部引入，而组件 B 的 b.css 在头部引入，B 的样式就可能意外压过 A。
- 固定加载顺序：基础公共样式 → 布局样式 → 页面级样式 → 组件样式（按依赖关系从底向上）
- 避免动态插入
<link>，尤其是通过 JS 注入，时序难控 - 可通过
document.styleSheets检查实际加载顺序，验证是否与预期一致 - 开发阶段用 Chrome DevTools 的 “Coverage” 面板识别未使用的 CSS 规则，避免冗余文件干扰
真正隔离需配合其他机制，仅靠 link 不够
独立 <link> 是组织手段，不是封装手段。要彻底防污染，得叠加一层作用域控制：
立即学习“前端免费学习笔记（深入）”；
- 启用 CSS Modules（需构建支持）：把
button.module.css中的.root编译成_root_abc123类名，配合import styles from './button.module.css'使用 - Shadow DOM（Web Components）：用
element.attachShadow({mode: 'closed'})创建样式边界，外部 CSS 完全无法穿透 - scoped 属性（Vue 单文件组件）：
<style scoped></style>会自动为选择器添加数据属性，如[data-v-f3f3eg9] - PostCSS 插件如
postcss-prefix-selector可批量为整个 CSS 文件加前缀，适合遗留项目渐进改造
/* 示例：postcss-prefix-selector 配置后，输入 */
.root { color: blue; }
.root:hover { color: red; }
<p>/<em> 输出 </em>/
.my-component .root { color: blue; }
.my-component .root:hover { color: red; }</p>独立 link 是可控拆分的第一步，但真正的样式隔离从来不是靠“放哪儿”，而是靠“怎么写”和“谁来管”。类名冲突、加载时序、全局规则蔓延——这些细节不卡死，再多的文件拆分也只是假隔离。
