scss中@import url("xxx.css")会绕过构建流程，原样输出为css运行时导入，导致postcss、autoprefixer等无法处理，sass变量不可用，且阻塞渲染、热更新失效。
直接在 SCSS 文件里写原生 CSS 的 @import url("xxx.css") 会绕过构建流程，导致样式无法被 PostCSS、Autoprefixer 或 CSS Modules 处理，且无法参与 Sass 变量/混合宏的编译——它本质上是“逃逸出预处理管道”的裸请求。
SCSS 文件中混用 @import url() 的实际行为
这不是 Sass 的 @import 指令，而是原生 CSS 的 @import 规则。Sass 编译器看到 @import "xxx.css"（带扩展名）或 @import url(...) 时，会原样保留该语句，不作任何文本替换，直接输出到最终 CSS 中。
- 浏览器加载时才发起 HTTP 请求，无法并行下载，阻塞渲染（和纯 CSS 中的
@import一样） - PostCSS 插件（如
autoprefixer）对这个语句后的规则无效，因为它是运行时引入，不在当前编译上下文中 - 无法使用 Sass 变量拼接路径，比如
@import url("#{$cdn}/base.css")在 Dart Sass 中会被拒绝（语法错误） - Webpack/Vite 的 CSS 提取插件（如
mini-css-extract-plugin）无法识别它为依赖，热更新失效
为什么开发者容易误写成 @import "xxx.css"
常见于想快速引入第三方 CSS 库（如 normalize.css、tailwind.css），又没注意文件后缀。Sass 对 .css 后缀的处理逻辑和 .scss/.sass 完全不同：
-
@import "normalize"→ 尝试找normalize.scss或normalize.sass，找不到报错 -
@import "normalize.css"→ 直接透传为@import url("normalize.css");，无编译干预 -
@import "tailwind"（无后缀）→ 若有tailwind.scss，正常导入；若只有tailwind.css，同样透传
正确替代方案：用 @use 或构建工具链引入
真正需要复用第三方样式逻辑时，应走模块化路径而非运行时加载：
- 优先查该库是否提供 SCSS 版本（如
bootstrap/scss/bootstrap），然后@use "bootstrap/scss/bootstrap" - 若只有 CSS，改用构建工具的
import语句：@import "@/styles/normalize.css";（Vite）或import "@/styles/normalize.css";（Webpack + style-loader） - 必须用原生
@import？只应在最终输出的 CSS 入口文件（如main.css）里写，并确保它位于最顶部，且不嵌套 - 绝对不要在
.scss文件里写@import url("xxx.css")—— 它既破坏编译流，又带来性能隐患
真正麻烦的不是语法报错，而是它悄无声息地把一部分样式踢出了整个构建体系：变量不生效、前缀不加、压缩不进 bundle、HMR 不触发。等上线后发现某几个按钮样式异常，再回头查，往往卡在“这行 @import 居然没被任何工具链管”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
