css 项目初始化时如何规划引入方式_css 项目结构建议_技术教程

直接用。它支持预加载、并行下载，而 @import 会阻塞解析、引发 FOUC，且嵌套时导致请求串行化；基础样式应通过显式引入，仅组件级 CSS 可少量使用 @import 引入变量。

项目初期该选 `@import` 还是引入 CSS？

直接用。浏览器对的预加载支持更好，能并行下载资源；而 @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，结果样式泄漏到其他模块