外部样式表能提升可维护性，但需配合构建工具链实现模块化、作用域隔离与依赖管理，否则易引发冲突、加载混乱和全局污染。
外部样式表在大型项目中是否真能提升可维护性
适合，但前提是组织方式合理。单纯把所有 CSS 拆成 .css 文件丢进 link 标签，并不能自动带来可维护性——反而容易陷入选择器冲突、加载顺序混乱、全局污染的泥潭。
为什么直接用 @import 或多个 link 会出问题
浏览器对每个 link 都发起独立 HTTP 请求（HTTP/1.1 下明显阻塞），@import 还会阻塞后续资源解析；更关键的是，它们不提供作用域隔离或依赖声明能力。
- 多个
link无隐式顺序保证（尤其动态插入时） -
@import在 CSS 文件内使用时，无法被 Webpack/Vite 等工具静态分析依赖 - 没有变量、嵌套、条件编译等能力，导致重复写
color: #333或margin: 1rem数百次
真正提升可维护性的做法：外部样式 + 构建工具链
外部样式本身只是载体，可维护性来自构建时的处理逻辑。核心是把 .css 替换为支持模块化、作用域和复用的方案。
- 用
postcss+postcss-nested+postcss-custom-properties补足原生 CSS 的短板 - 启用 CSS Modules（如
Button.module.css），让className自动哈希，避免全局污染 - 按功能拆分文件：
reset.css、variables.css、layout.css、component/Button.css - 通过构建工具合并压缩，最终只输出一个
main.css，兼顾开发体验与运行时性能
容易被忽略的关键点：CSS 作用域边界必须显式定义
即使用了外部样式，只要还在写 .header 这种全局类名，就随时可能被另一个 .header 覆盖。真正的维护性来自约束，不是路径。
立即学习“前端免费学习笔记（深入）”；
- 避免在外部样式中写无上下文的顶层选择器，如
h2 { color: red; } - 组件级样式优先用
:where(.MyComponent) h2或 CSS Modules 的局部作用域 - 设计系统层的原子类（如
text-lg、bg-primary）需配合tailwind.config.js统一管控，而不是散落在多个.css里
外部样式表不是银弹，它只是把“怎么组织样式”的问题从 HTML 内联转移到了文件结构和构建流程里——而后者恰恰是大型项目最常回避、也最容易失控的部分。
