老项目直接加 @import 会炸包且首屏白屏或样式错位，因其同步阻塞渲染、构建工具不识别路径、导致 HMR 失效和 Tree Shaking 失效；生产环境应禁用，仅开发临时可用。
老项目直接加 @import 会炸包吗
会，而且大概率首屏白屏或样式错位。原生 @import 是 CSS 解析时同步阻塞的，浏览器必须等它加载、解析完才能继续渲染后续样式——哪怕你只在 page-home.css 里 @import 'base.css'，整个页面都会卡住等这个请求返回。
更糟的是：Webpack/Vite 根本不识别这种写法，@import 'vars.css' 中的路径不会被 resolve，构建时报 Can't resolve './vars.css' 是常态；HMR 失效、样式重复打包、Tree Shaking 彻底失效也都跟着来。
- 别碰生产环境的
@import，它不是模块化，是加载陷阱 - 开发阶段临时用可以，但上线前必须走构建工具链处理
- 如果老项目没构建工具（纯 HTML + link），那
@import是唯一选择，但得接受多 1–2 个 HTTP 请求和不可控的加载顺序
Webpack 项目怎么安全接入 CSS Modules
关键不是重写所有样式，而是“让新代码模块化，旧代码不动”。CSS Modules 的隔离性只作用于 JS 模块内，不影响全局已有的 class。
- 文件名必须带
.module.css后缀，比如header.module.css，否则css-loader不启用模块化 - 在组件中用
import styles from './header.module.css'，然后className={styles.root}—— 这样生成的类名是哈希化的，和老页面里的class="header"完全不冲突 - 老 HTML 模板里继续用原有 class，JS 里
document.querySelector('.old-button')照常工作，不受影响 - 禁用
css-loader的modules: true全局模式，改用modules: { mode: 'local' }，避免误伤第三方 CSS
没有构建工具的老项目怎么拆又不改 HTML
只能靠路径收敛 + 预加载兜底。目标是让拆分后的文件能被浏览器按需加载，同时不改变现有 DOM 结构和 class 名。
立即学习“前端免费学习笔记（深入）”；
- 把原
app.css拆成base.css、layout.css、components.css，全部放在同一目录下，用相对路径引用 - 在 HTML 的
<head>里用<link rel="preload" href="/css/base.css" as="style" onload="this.onload=null;this.rel='stylesheet'">提前声明资源，避免阻塞 - 用 JS 动态插入其余 CSS：
const link = document.createElement('link'); link.rel = 'stylesheet'; link.href = '/css/layout.css'; document.head.appendChild(link); - 不要依赖
document.styleSheets.length判断加载完成，改用link.addEventListener('load', callback)
为什么不能一边用 @import 一边用 import 在 JS 里
因为它们根本不在一个体系里：@import 是 CSS 层的同步加载指令，import 是 JS 模块系统的异步依赖声明。混用会导致样式注入时机完全失控。
- JS 中
import './button.css'走的是 webpack 的style-loader或MiniCssExtractPlugin，样式插入时机由 JS 执行顺序控制 - CSS 文件里
@import 'theme.css'是浏览器在解析该 CSS 时发起的第二个请求，时间点不可预测 - 结果就是：按钮样式可能先加载，主题色后加载，导致按钮先显示默认灰再闪成蓝色——这不是 bug，是机制冲突
- 统一入口：所有样式都从 JS
import进来，CSS 文件里只写规则，禁用一切@import
最易被忽略的一点：老项目往往有内联样式、!important、深度选择器（如 .page .content p），这些会穿透模块化隔离。拆分前先 grep 出高频 class 和强覆盖规则，优先封装进新模块，而不是直接删掉旧样式。
