一律用，别碰@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？
除非团队已熟练使用且项目明确需要动态主题或极致复用，否则初期别碰。
立即学习“前端免费学习笔记（深入）”；
原因很实际：
- CSS-in-JS（如 Emotion、Styled-components）会把样式逻辑和组件耦合，初期页面少时看不出问题，一旦要抽离公共样式或做 SSR 优化，就得补大量适配层
- 原子化 CSS（如 Tailwind）省了写类名时间，但调试时你会频繁在 DevTools 里看到
flex items-center p-4 bg-gray-50 rounded-lg这种长串，查来源难，改起来也难定位是哪个业务逻辑塞的 - 纯 CSS 分层结构 + BEM 命名（如
button--primary、card__header）已经能覆盖 90% 初期需求，学习成本低，交接无障碍
如果真要用 Tailwind，至少把 @layer components 和 @layer utilities 分开管理，别全堆在同一个 tailwind.css 里。
变量和响应式断点放在哪一层最不容易后期返工？
统一收口到 base/variables.css，且只放两类内容：
- 设计系统级常量：颜色、字体大小、间距比例、圆角、阴影值（用
calc()或clamp()包一层也行） - 断点数值本身：如
--breakpoint-sm: 640px、--breakpoint-lg: 1024px，但不要直接写@media (min-width: var(--breakpoint-lg))在这里
所有媒体查询必须下沉到具体文件中（components/button.css 里自己写 @media (max-width: var(--breakpoint-sm))），这样改断点数值时，只需改一个地方；而各组件是否响应、怎么响应，由各自文件决定——避免出现“改了断点，所有按钮都塌了”的连带故障。
真正容易被忽略的是：变量命名一旦定下，就别轻易加「dark:」前缀或「motion-safe:」这类状态修饰。初期先做亮色模式，暗色模式等数据层和主题切换机制跑通后再扩展，不然变量爆炸式增长，维护成本翻倍。
