现代项目中禁用 CSS @import 拆文件，因其串行加载、引发 FOUC；应改用构建工具的 import + CSS 提取机制实现按需加载、作用域隔离与缓存优化。
用 @import 拆文件？别这么干
现代项目里直接用 @import 拆 CSS 文件，等于主动给页面加加载阻塞。它会串行请求、无法并行下载，还可能触发 FOUC（闪白），尤其在旧版 Safari 和部分移动端 WebView 里更明显。
常见错误现象：index.css 里写了十几个 @import，首屏渲染卡顿，DevTools Network 面板看到样式文件排长队。
- 浏览器解析到
@import才发起新请求，不是一开始就并发拉 - Webpack/Vite 等构建工具默认不处理 CSS 中的
@import（除非配了专门 loader） - HTTP/2 虽缓解了部分问题，但语义上仍是“同步依赖”，不利于代码分割和缓存复用
真正按需导入：用构建工具做 import + css 提取
核心是让 JS 控制 CSS 加载时机，而不是靠 HTML link 或 CSS @import。比如某个弹窗组件只在点击后才需要样式，就该让它和组件逻辑一起被 import。
使用场景：按路由拆分、组件级样式隔离、主题切换时动态加载特定 CSS 包。
立即学习“前端免费学习笔记（深入）”；
- 在 JS 中写
import './Dialog.module.css'（CSS Modules）或import './theme-dark.css' - 配置 Webpack 的
MiniCssExtractPlugin或 Vite 的build.cssCodeSplit，把 import 进来的 CSS 抽成独立 chunk - 确保输出的 CSS 文件名带 hash，避免缓存问题；否则改了样式用户看不到
示例（Vite）：
export function loadDarkTheme() {
return import('./themes/dark.css')
}这样调用后，dark.css 才会被打包进单独的 chunk 并动态插入 <link>。
模块化命名和作用域：别让 .button 全局污染
拆成小文件不等于解决样式冲突。如果每个 button.css 都定义 .button，最后合并还是打架。
参数差异：CSS Modules 默认开启局部作用域，而普通 import './button.css' 是全局注入。
- 优先用
xxx.module.css后缀，让构建工具自动哈希类名，如Button_button__abc123 - 不用 Modules 时，约定 BEM 命名（如
.c-dialog__header），并靠目录约束作用域（components/Dialog/Dialog.css只写 Dialog 相关样式） - 警惕
:global(...)写法——容易误放，一不小心就把局部样式又打到全局了
要不要用 CSS-in-JS？看团队和运行时成本
拆 CSS 文件只是手段，目标是降低维护复杂度和避免冲突。CSS-in-JS（如 Emotion、Styled Components）也能做到模块化+按需，但它把样式逻辑耦合进 JS 打包流程里。
性能影响：服务端渲染时多一次 JS 解析；首屏 JS 包体积变大；部分低配设备重绘略慢。
- 适合强交互组件（需要根据 props 动态生成样式）、设计系统驱动的项目
- 不适合纯静态站点或对 TTI（Time to Interactive）极度敏感的落地页
- 注意 SSR 时的 class 名一致性，否则 hydration 会出错，报类似
Prop `className` did not match的警告
真要选，优先试 Linaria 这类零运行时方案——编译期提取 CSS，最终输出仍是标准 CSS 文件，能享受所有传统优化。
拆 CSS 不是堆文件数量，而是让每一块样式有明确归属、可预测的加载时机、可控的作用域。最常被忽略的是：没配好构建工具的 CSS 提取规则，结果拆了一堆 .css，最后全被打包进一个 style.css 里，白忙活。
