@import 会阻塞页面渲染，因其同步串行加载机制；路径解析以当前CSS文件为基准；媒体查询不延迟加载；构建产物中残留@import暴露源码且影响性能。
使用 @import 会导致页面渲染阻塞
浏览器解析 CSS 时，@import 是同步、串行加载机制：遇到一个 @import，必须等它下载、解析完，才能继续处理后续样式。这会显著拖慢 render tree 构建，尤其在多层嵌套（如 @import 套 @import）时，首屏白屏时间明显增加。
- 不要在主 CSS 文件顶部写
@import url("theme.css");，它比<link rel="stylesheet">多一次 HTTP 往返且无法并行 - 若必须动态引入（如主题切换），改用 JS 动态创建
<link>标签，配合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 解析阶段下载该文件（只是不参与屏幕渲染）。它不节省带宽，也不提升首屏性能。
- 真正延迟加载应使用
<link media="print" href="print.css">，现代浏览器对此有优化，非匹配媒体类型资源默认惰性下载 -
@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，基本等于性能没过关。
