公共CSS文件应放在src/assets/styles/下、命名为base.css，避免index.css；仅放入重置样式、CSS变量、纯布局工具类，禁用业务语义类和!important规则。
公共CSS文件该放哪、叫什么名才不踩包管理的坑
组件化项目里把样式抽成独立base.css或common.css没问题，但路径和命名一错，就会出现样式漏加载、重复打包、甚至被CSS-in-JS方案自动剔除的情况。
常见错误现象：button组件用了.text-sm，但编译后没生效；或者build产物里同一套重置样式出现了三次。
- 路径必须在构建工具能“静态分析到”的范围内——比如放在
src/assets/styles/下，而不是src/components/common/这种容易被当成模块路径处理的目录 - 文件名避免用
index.css，某些打包器（如Vite + CSS提取插件）会把它当作模块入口自动合并，导致顺序不可控 - 如果项目用Webpack，确保
css-loader的importLoaders没意外吞掉@import链；Vite用户则要确认css.preprocessorOptions没干扰@import解析
哪些样式适合放进基础CSS文件，哪些坚决不能放
不是所有“看起来通用”的类都该进base.css。放错了，后期改一个.btn可能牵出二十个组件的视觉回归测试。
使用场景决定取舍：基础重置、排版比例、色彩变量、辅助工具类（如.sr-only、.visually-hidden）可以放；但带业务语义的类（如.card-header、.user-avatar）哪怕多个组件都用，也属于组件内部实现细节，不该暴露为全局。
立即学习“前端免费学习笔记（深入）”；
- ✅ 推荐放：
*, *::before, *::after盒模型重置、:root里的--color-primary等CSS变量、.flex-center这类纯布局工具类 - ❌ 坚决不放：
.header-nav（耦合导航结构）、.price-tag（含业务含义）、任何带!important的规则（基础层不该越权） - ⚠️ 警惕伪通用：
.text-bold看着中立，但如果设计系统里“加粗”只用于标题，那它本质是语义类，应由Heading组件控制，而非全局类
如何让基础CSS在组件内可控地生效，又不污染全局
直接在main.js里import '@/assets/styles/base.css'最简单，但问题在于：某些组件（比如微前端子应用、Storybook隔离环境）需要独立样式上下文，全局注入就失控了。
性能影响很明显：基础CSS一旦体积超过2KB，未压缩状态下会阻塞首屏渲染；兼容性上，IE11不支持:root变量，但你又不能为它单独写一套base.css。
- 推荐做法：用
link rel="stylesheet"在index.html头部引入，确保它永远是CSSOM第一顺位——比任何组件内import都早执行 - 如果必须动态控制（比如主题切换），把变量抽成
theme.css单独加载，base.css只保留无状态规则（重置、工具类） - Vue用户注意：
<style>标签加scoped不会影响base.css里的全局类，但若组件用了deep穿透并覆盖了.text-sm，那就是优先级问题，不是复用逻辑失败
为什么CSS变量要和基础文件解耦，单独管理
很多人把--color-bg直接写进base.css，结果换肤时要改两处：变量定义 + 对应的.bg-white类实现。这不是复用，是硬编码。
真正复用的关键是“分离声明与使用”。变量本身是设计契约，不是样式实现；而base.css是运行时产物，该专注规则而非配置。
- 变量统一放
src/assets/styles/variables.css，用@layer base包裹（支持@layer的浏览器优先级更稳） -
base.css里只写.bg-bg { background-color: var(--color-bg); }，不写具体值 - 构建时若需生成多主题CSS，只需替换
variables.css内容，base.css完全不动——这才是可维护的复用
复杂点在于：CSS变量无法被PostCSS的nesting或custom-properties插件静态分析，所以var(--color-bg)拼错也不会报错，只能靠CI跑样式快照比对。这点容易被忽略。
