旧项目中直接使用sass:meta报错，是因为该模块仅在Dart Sass 1.23+中稳定支持，而旧项目多采用@import或低版本Sass编译器（如sass-loader
为什么旧项目里直接用 sass:meta 会报错
因为 sass:meta 是 Dart Sass 1.23+ 才正式稳定支持的模块，旧项目若还在用 @import 或低版本 Sass 编译器，@use "sass:meta" 会直接失败。更常见的是：你升级了 CLI，但构建脚本里没更新 sass 版本，或者 Webpack 的 sass-loader 锁在旧版（如 v10.x），它默认调用的是内置老 Sass 引擎。
验证方式很简单：sass --version 输出必须是 1.23.0 或更高；若用 sass-loader，检查其文档是否标明支持 @use "sass:meta" —— v12.6+ 才完全兼容。
- 旧项目中混用
@import和@use会导致sass:meta不可用，必须全量切换 -
sass:meta不提供运行时能力，它只在编译期暴露函数，比如meta.module-variables()查当前模块变量，不能用来动态读取 CSS 自定义属性 - 别在
@forward入口文件里@use "sass:meta"后再转发它的函数——sass:meta不支持@forward，只能在具体工具文件里单独@use
meta.load-css 怎么安全注入旧样式而不破坏 BEM 隔离
旧项目常有大量内联 <style></style> 或第三方库 CSS，想用 meta.load-css 把它们转成 Sass 模块复用，但直接 @use "legacy.css" 会把所有选择器丢进全局作用域，立刻污染 BEM 模块边界。
正确做法是加一层 wrapper class 封装：
立即学习“前端免费学习笔记（深入）”；
@use "sass:meta";
@use "legacy" as *;
// 把 legacy.css 内容包裹进 .legacy-wrapper
$legacy-css: meta.load-css("legacy.css");
@use "sass:meta";
@use "legacy" as *;
// 注入前手动加前缀（需配合 postcss-prefixwrap 或自写正则）
// 或更稳妥：只用 meta.load-css 加载纯变量/函数片段，不加载规则
-
meta.load-css只接受.css文件，不支持.scss；它不会解析@media或嵌套，只提取顶层规则 - 它无法处理
!important、CSS Custom Properties 的 fallback 值，这些会被原样保留，可能和新变量冲突 - 真正推荐的迁移路径是：用
meta.load-css提取旧文件里的颜色/尺寸值，生成_legacy-variables.scss，再让新模块@use它，而不是加载整份样式
meta.get-function 和 meta.get-mixin 如何避免重构时调用失效
旧项目里大量用 @include clearfix 或 @include responsive-font(16px)，但迁移到 @use 后，这些名称不再全局可见。有人想用 meta.get-mixin("clearfix") 动态调用，结果发现它只返回 mixin 引用，不能直接执行 —— 这是最大误区。
meta.get-mixin 返回的是一个“可调用对象”，必须用 @include call(...) 才能触发，且参数必须严格匹配签名：
@use "sass:meta";
@use "utils/mixins" as u;
@include meta.call(u.$clearfix); // ✅ 正确
@include u.clearfix; // ✅ 更推荐：直接命名空间调用
@include meta.get-mixin("clearfix"); // ❌ 报错：call() 缺失
-
meta.get-function同理，返回函数引用，必须用@return call(...)，不能直接function-name(...) - 旧项目若存在同名 mixin 在多个文件中定义（如两个
_mixins.scss都有clearfix），meta.get-mixin会随机返回一个，无法预测 —— 必须先清理命名冲突 - 不要用它绕过命名空间：写
u.clearfix比meta.call(u.$clearfix)更清晰、更易调试
重构时最容易被忽略的 meta 边界问题
sass:meta 的函数不是万能胶水，它解决不了旧架构里最顽固的问题：隐式依赖和 DOM 假设。比如一个旧 _grid.scss 里写了 .row > .col，它假设 HTML 结构固定；你用 meta.module-variables("grid") 查到 $gutter，但改了这个变量，JS 插件计算列宽的逻辑可能就崩了。
这类问题不会报 Sass 编译错误，但上线后行为异常。真正要盯住的是：
- 旧 JS 代码里硬编码的类名（如
el.classList.add("is-active")），meta模块完全无法感知 - 通过
document.styleSheets动态读取 CSSRule 的旧逻辑，meta.load-css加载的内容不会出现在运行时样式表中 -
meta.inspect返回的字符串含换行和空格，直接拼进@debug可读性差，别用它做自动化校验，仅作调试辅助
