升级sass-loader后构建崩溃主因是配置字段名变更（如data→additionaldata）、api语义变化及对node-sass兼容性移除；需按版本严格匹配构建工具链，并将includepaths等移入sassoptions，同时将@import改为@use显式引入变量。
为什么升级 sass-loader 后构建直接崩了
绝大多数报错不是因为版本号写错了，而是 sass-loader 配置项字段名变了、API 语义变了，或者它悄悄放弃了对 node-sass 的兼容。比如 sass-loader@12+ 彻底移除了 data 字段（旧版叫 data，新版叫 additionalData），用错就触发 ValidationError: Invalid options object；又比如 sass-loader@14+ 默认要求 sass@1.75.0+，但老项目里还混着 node-sass，结果 loader 自动 fallback 回去，编译却卡在不支持的语法上。
sass-loader 版本必须和构建工具对齐
别只看“最新版”，得看你的构建链是否撑得住：
-
Vue CLI 4.x→ 锁死用sass-loader@12.6.0，配sass@1.70.0（sass@1.75.0+会要求sass-loader@14，而 Vue CLI 4 不支持） -
Vue CLI 5+/Vite 4+→ 可用sass-loader@13+或直接用 Vite 内置逻辑，不用显式装sass-loader -
Webpack 5 + 手动配置→ 推荐sass-loader@13.3.2+sass@1.79.0（适配 Element Plus 2.8.5+ 等主流 UI 库） - 若项目还在用
node-sass，先npm uninstall node-sass，再装新包——共存时sass-loader会优先选node-sass，哪怕你写了implementation: require("sass")
配置项字段名和值必须按新版 API 写
旧配置里常见的 data、includePaths、outputStyle 全部挪到了 sassOptions 下，且部分行为已变更：
-
additionalData替代旧版data：内容必须是字符串，且路径要能被 Sass 解析（@use "@/styles/vars" as *中的@/要靠 Webpackresolve.alias提前定义） -
includePaths不再直接挂在sass-loader options顶层，得塞进sassOptions里：sassOptions: { includePaths: ["node_modules"] } -
webpackImporter: true在sass-loader@12+中默认启用，除非你明确关掉，否则不用写；但 Angular 项目仍需在angular.json里补stylePreprocessorOptions.includePaths - Vite 用户注意：
css.preprocessorOptions.sass下不能写javascriptEnabled: true（Dart Sass 已废弃该选项），要用api: "modern-compiler"和silenceDeprecations: ["legacy-js-api"]
@import 没报错但变量用不了，其实是 @use 语义没跟上
升级后最隐蔽的问题不是构建失败，而是样式“看起来正常，但颜色/间距全乱了”——根源是 Dart Sass 不再把 @import 当全局污染，所有变量、函数都得显式引入：
- 原来
@import "variables"后直接用$primary-color→ 现在必须@use "variables" as v，然后写v.$primary-color - 想保持全局可用？只能
@use "variables" as *，但要注意命名冲突（比如两个文件都导出$radius） - 第三方库（如 Bootstrap）若仍用
@import，确保其package.json的"sass"字段指向的是.scss入口，而不是已弃用的.sass文件 - 路径必须带
./或../：@use "utils"会失败，得写@use "./utils"或@use "~@/styles/utils"（前提是 alias 已配好）
真正容易被忽略的点是：即使所有配置都改对了，只要项目里还残留一个 @import 且没转 @use，Dart Sass 就不会把那个文件里的变量注入到当前作用域——它不“传染”，只“显式引用”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
