直接用 。它支持预加载、并行下载，而 @import 会阻塞解析、引发 FOUC，且嵌套时导致请求串行化；基础样式应通过 显式引入，仅组件级 CSS 可少量使用 @import 引入变量。
项目初期该选 @import 还是
直接用 。浏览器对 的预加载支持更好，能并行下载资源；而 @import 是 CSS 内部语法，会阻塞后续样式解析，且在 @import 嵌套多层时容易引发 FOUC（Flash of Unstyled Content）。
常见错误：在 index.css 里写一堆 @import './reset.css'; @import './vars.css'; —— 这会让 HTTP 请求串行化，尤其在 HTTP/1.1 下明显拖慢首屏渲染。
- 所有基础样式（重置、变量、工具类）都通过
在 HTML 中显式引入 - 只在组件级 CSS（如 React 的
Button.module.css）中用@import拉少量共用变量，且禁止跨层级嵌套 - 构建工具（Vite/Webpack）默认把
@import提取合并，但开发时仍受解析顺序影响，别依赖它“自动优化”
如何组织 src/css/ 目录结构才不踩坑？
按「作用域」而非「类型」分层。别建 src/css/utils/、src/css/components/、src/css/pages/ 这种平行目录——它们会快速失控，导致变量重复、覆盖难查、复用率低。
推荐结构：
立即学习“前端免费学习笔记（深入）”；
src/css/ ├── base/ /* 全局基础：reset、fonts、prefers-reduced-motion */ ├── tokens/ /* 设计令牌：colors.css、spacing.css、breakpoints.css */ ├── layout/ /* 布局容器：grid.css、container.css、header-footer.css */ ├── components/ /* 原子组件：button.css、input.css、card.css（不带业务语义）*/ └── app/ /* 应用层：dashboard.css、profile.css（可含 BEM 命名）*/
关键点：
-
tokens/必须用 CSS 自定义属性（--color-primary），避免 Sass 变量，方便 JS 运行时读取和主题切换 -
components/中禁止写具体尺寸或颜色值，全部引用tokens/中的变量 -
app/层才允许组合使用、加业务命名，也才是唯一允许出现.dashboard-sidebar这类名字的地方
要不要一开始就上 CSS-in-JS 或 Tailwind？
看团队规模和交付节奏。小项目（
典型误判：
- 为“未来可能换主题”提前引入 Emotion 或 Styled Components —— 实际上线后 90% 样式仍靠全局 CSS 控制，JS 部分反而成了维护黑洞
- 在没有设计系统支撑时强行用 Tailwind，导致
class="p-4 bg-blue-600 text-white rounded-lg shadow-md hover:bg-blue-700"散落在各处，改一个色要搜 20 个文件 - 用 PostCSS 插件（如
postcss-nested）模拟 Sass 结构，却没配好 source map，报错定位到压缩后的一行
务实做法：先用纯 CSS 写通首页 + 登录页，跑通构建、变量注入、媒体查询响应流程，再决定是否引入额外方案。
构建时 CSS 提取和作用域隔离怎么做？
Webpack/Vite 默认开启 mini-css-extract-plugin 或 cssCodeSplit，但要注意两点：
- 确保
node_modules中第三方 CSS（如normalize.css）被单独打包成vendor.css，避免每次修改业务 CSS 都让浏览器重新下载基础样式 - 模块化 CSS 必须启用
localsConvention: 'camelCase'（Webpack）或modules: { localsConvention: 'camelCase' }（Vite），否则btn__icon无法在 JS 中正确解构为btnIcon - 慎用
:global()—— 它会绕过作用域，但开发者常忘记加:global(.legacy-header)而写成.legacy-header，结果样式泄漏到其他模块
最易忽略的点：CSS 源码映射（source map）在生产环境默认关闭，但调试阶段必须打开；否则 Chrome DevTools 里看到的行号全是 bundle.css:1，根本没法定位问题。
