17370845950

@import 会阻塞页面渲染，因其同步串行加载机制；路径解析以当前CSS文件为基准；媒体查询不延迟加载；构建产物中残留@import暴露源码且影响性能。

使用 @import 会导致页面渲染阻塞

浏览器解析 CSS 时，@import 是同步、串行加载机制：遇到一个 @import，必须等它下载、解析完，才能继续处理后续样式。这会显著拖慢 render tree 构建，尤其在多层嵌套（如 @import 套 @import）时，首屏白屏时间明显增加。

• 不要在主 CSS 文件顶部写 @import url("theme.css");，它比 多一次 HTTP 往返且无法并行
• 若必须动态引入（如主题切换），改用 JS 动态创建 标签，配合 onload 控制行为
• 构建工具（如 Webpack/Vite）中，@import 通常被预处理合并，此时实际不产生运行时请求 —— 但要确认最终产物里没有残留未展开的 @import

@import 的路径解析以当前文件为基准

很多人误以为 @import 的 URL 是相对于 HTML 页面位置，其实它是相对于包含该 @import 声明的 CSS 文件路径。例如：base.css 在 /static/css/base.css，其中写了 @import "reset.css";，浏览器会请求 /static/css/reset.css，而不是根目录下的 /reset.css。

• 绝对路径（@import "/css/vars.css";）可避免歧义，但会丧失模块迁移灵活性
• 相对路径易出错，尤其项目结构重组后，建议统一用构建工具别名（如 @import "~@styles/normalize.css";）
• 注意 URL 中的引号：单引号、双引号、无引号都合法，但带空格或特殊字符时必须加引号

媒体查询 + @import 不等于响应式按需加载

写成 @import url("print.css") print; 看似“只在打印时加载”，但浏览器仍会在初始 HTML 解析阶段下载该文件（只是不参与屏幕渲染）。它不节省带宽，也不提升首屏性能。

• 真正延迟加载应使用 ，现代浏览器对此有优化，非匹配媒体类型资源默认惰性下载
• @import 后跟媒体查询仅控制规则是否生效，不影响资源获取时机
• 不要用 @import (max-width: 768px) { ... } —— 这是非法语法，CSS 规范不支持条件块内嵌 @import

构建产物中残留 @import 可能暴露源码结构

某些打包配置（如 PostCSS 未启用 postcss-import 或设置 skipDuplicates: false）会导致输出 CSS 里还留着原始 @import，不仅增加请求数，还可能把开发期路径（如 @import "../../node_modules/xxx/index.css";）直接暴露到生产环境。

/* 错误示例：构建后未展开 */
@import "vars.css";
@import "components/button.css";
@import "layout/grid.css";

• 检查最终生成的 CSS 文件，搜索 @import，确认是否清零
• Vite 用户需确保 css.preprocessorOptions 或插件未禁用 import 解析
• Webpack + css-loader 需开启 importLoaders 并配好 postcss-loader

关键点在于：只要还在运行时执行 @import，就绕不开它的同步阻塞本质。真正安全的用法，只存在于构建阶段的静态解析。线上看到 @import，基本等于性能没过关。