一律用，别碰@import；因其阻塞解析、串行加载，而支持并行及条件加载；生产环境禁用CSS内@import，构建工具应处理合并。
项目初期该用 @import 还是
直接上结论：一律用 ，别碰 @import。@import 会阻塞并延迟 CSS 解析，尤其在多层嵌套时，浏览器必须串行下载、解析完前一个文件才能读下一个，首屏渲染明显变慢。而 支持并行加载，还能配合 media 或 preload 做条件加载或预加载。
- 生产环境禁止在 CSS 文件里写
@import（哪怕只导入一个变量文件） - HTML 中多个样式表，用多个
并列写，别为了“整洁”合并成一个@import链 - 如果用构建工具（如 Vite、Webpack），让它们处理合并逻辑，而不是靠 CSS 语法层面的
@import
如何分层组织 CSS 文件结构？
分层不是为了炫技，是让「改按钮颜色」和「重构响应式断点」互不干扰。推荐四层结构，从通用到具体：
-
base/：重置（normalize.css或自定义reset.css）、根变量（:root里的--color-primary）、基础字体/排版规则 -
layout/：栅格系统、容器（.container）、页眉页脚通用结构、全局 flex/grid 工具类 -
components/：独立可复用模块，如button.css、card.css，每个文件只负责一个组件，不依赖其他组件文件 -
pages/或views/：页面级样式，仅用于解决「这个页面独有的布局组合问题」，比如首页轮播+列表混排，禁止在这里写按钮样式或颜色变量
关键约束：下层可以引用上层（components/button.css 可以用 base/variables.css 的变量），但绝不可反向引用。否则改个颜色变量，整个 pages/ 都得测一遍。
要不要一开始就上 CSS-in-JS 或原子化 CSS？
除非团队已熟练使用且项目明确需要动态主题或极致复用，否则初期别碰。
立即学习“前端免费学习笔记（深入）”；
原因很实际：
