一、老旧项目里的@import“隐形坑”
做过前端项目的人都知道，项目跑个两三年，代码就容易堆得像乱麻，尤其是样式文件，改个小地方都要翻半天。很多老项目的样式都用@import来引入其他样式文件，看起来方便，实际用起来全是坑。我之前接手过一个运营后台的老项目，改个按钮样式，居然改完后导航栏的文字颜色变了，查了半天才发现，是两个样式文件里的同个类名冲突了，根源就是@import的引入逻辑有问题。
简单说，@import的核心问题是它不会隔离样式作用域，所有引入的样式都会“揉”到一起，就像把所有菜倒进同一个锅里，分不清谁是谁的调料。而且@import的引入顺序特别敏感，后引入的文件会覆盖前面的同规则样式，要是项目里有几十个@import，顺序乱了就全乱套。另外，@import在CSS里是串行加载的，也就是说浏览器要等前一个@import的样式加载完，才会加载下一个，大项目里这会拖慢页面加载速度，用户打开页面要等半天样式才出来。
二、@use是什么？凭什么能解决@import的问题
@use是Sass（现在也叫Dart Sass）里的新语法，专门用来替代@import的，它的核心是给每个样式文件加了“命名空间”，就像给每个菜装了单独的盘子，调料不会混。举个例子，你有两个样式文件，分别写了按钮和导航的样式，用@use引入的话，这两个文件里的同个类名不会冲突，因为每个文件的样式都属于自己的“空间”，调用的时候要加上空间名，不会互相干扰。
而且@use的加载是并行的，浏览器会同时加载所有用@use引入的样式文件，加载速度比@import快很多。另外，@use默认只加载一次，就算你在多个地方引入同一个文件，也不会重复加载样式，避免了样式重复的问题。
这里要先明确，所有示例用的技术栈是Dart Sass（版本1.50.0及以上，因为低版本可能不支持部分@use特性），后面的代码示例都基于这个技术栈。
三、平滑迁移的核心步骤（带完整示例）
迁移不是把所有@import直接换成@use就行，得一步步来，不然容易出问题。我之前迁移过一个有80多个样式文件的老项目，用了下面的步骤，基本没出大问题。
3.1 第一步：梳理项目里的@import依赖
先把项目里所有用@import的地方找出来，整理成一张依赖图，看看哪些文件互相引入，有没有循环引入的情况。比如老项目里可能有这样的代码：
// 老项目的main.scss（入口样式文件）
@import "reset.scss"; // 重置样式
@import "button.scss"; // 按钮样式
@import "nav.scss"; // 导航样式
@import "footer.scss"; // 页脚样式
先把这些依赖关系列出来，比如reset.scss是所有文件的基础，button.scss、nav.scss、footer.scss是子模块，这样迁移的时候就知道先改哪个后改哪个。
3.2 第二步：逐个替换@import为@use，添加命名空间
替换的时候要注意，@use引入的文件默认是带命名空间的，命名空间就是文件名（不带后缀），比如引入button.scss，命名空间就是button。调用里面的样式时，要加命名空间前缀，比如button里面的.btn类，就要写成button.btn。
比如把上面的main.scss替换成@use：
// 技术栈：Dart Sass 1.50.0
// 新的main.scss（入口样式文件）
@use "reset.scss"; // 重置样式，默认命名空间reset
@use "button.scss"; // 按钮样式，默认命名空间button
@use "nav.scss"; // 导航样式，默认命名空间nav
@use "footer.scss"; // 页脚样式，默认命名空间footer
// 调用按钮样式的例子（比如在页面组件里用）
.my-page-button {
@extend button.btn; // 继承button模块里的.btn样式
background-color: red; // 自定义样式
}
如果觉得命名空间太长，或者文件名有重复，还可以用as关键字给命名空间起别名，比如：
// 技术栈：Dart Sass 1.50.0
@use "components/button.scss" as btn; // 给button.scss起别名btn
@use "utils/reset.scss" as reset; // 给reset.scss起别名reset
// 调用别名的例子
.my-btn {
@extend btn.btn;
color: reset.$text-color; // 调用reset模块里的变量$text-color
}
3.3 第三步：处理变量和混合（@mixin）的引用
老项目里很多变量和混合是放在公共文件里的，比如variables.scss，用@import的时候，只要引入一次，所有文件都能直接用。但用@use的话，每个要用到变量或混合的文件都要单独引入，或者用@use的with关键字来传递变量，这样更灵活。
比如老项目里的variables.scss：
// 技术栈：Dart Sass 1.50.0
// 老的variables.scss
$primary-color: #1677ff; // 主色调
$text-size: 14px; // 文字大小
老项目里的button.scss直接用这些变量：
// 技术栈：Dart Sass 1.50.0
// 老的button.scss（用@import引入variables）
@import "variables.scss";
.btn {
color: $primary-color;
font-size: $text-size;
}
迁移后，button.scss要改成用@use引入variables：
// 技术栈：Dart Sass 1.50.0
// 新的button.scss（用@use引入variables）
@use "variables.scss" as var; // 引入variables，别名var
.btn {
color: var.$primary-color; // 调用var模块里的$primary-color
font-size: var.$text-size; // 调用var模块里的$text-size
}
如果要修改公共变量的值，比如在某个页面里把主色调改成红色，就可以用with关键字：
// 技术栈：Dart Sass 1.50.0
// 页面里的样式文件，修改公共变量
@use "variables.scss" as var with (
$primary-color: #ff4d4f // 把主色调改成红色
);
.my-page {
color: var.$primary-color; // 这里的主色调就是红色
}
3.4 第四步：测试和回滚
迁移完一个模块就要测试，比如改完按钮模块，就要看所有按钮的样式是不是正常，有没有冲突。如果发现问题，比如某个样式找不到，大概率是命名空间没加，或者引入路径错了。可以先回滚这个模块的修改，再检查哪里错了，不要等所有模块都改完再测试，那样问题太多不好找。
我之前迁移的时候，就遇到过一个问题：老项目里有个common.scss，里面同时写了按钮和导航的样式，用@import的时候直接引入就行，用@use的时候，我把它拆成了button.scss和nav.scss，然后在main.scss里分别引入，结果测试的时候发现导航样式没加载，查了半天才发现是引入路径错了，把nav.scss写成了nav.css，改过来就好了。
四、迁移的应用场景、优缺点和注意事项
4.1 应用场景
不是所有项目都需要迁移，只有当项目出现这些情况时，迁移才是值得的：
- 项目样式经常出现类名冲突，改一个地方影响其他地方；
- 项目样式加载慢，用户打开页面要等很久才显示样式；
- 项目需要多人协作开发，不同人写的样式容易互相干扰；
- 项目需要维护很久，后续还要加很多新功能，样式会越来越多。
4.2 迁移的优缺点
迁移的优点很明显：
- 样式隔离，不会出现类名冲突，改一个模块的样式不会影响其他模块；
- 加载速度快，@use是并行加载，比@import的串行加载快很多；
- 维护方便，每个模块的样式独立，找问题改问题都很容易；
- 支持变量传递，用with关键字可以灵活修改公共变量，适合多主题的项目。
迁移的缺点也有：
- 迁移工作量大，尤其是老项目样式文件多的话，要逐个替换；
- 学习成本，要熟悉@use的命名空间、别名、with关键字等语法；
- 依赖问题，老项目的依赖关系如果很复杂，梳理起来很麻烦。
4.3 注意事项
- 不要一次性全改，要分模块迁移，比如先改基础样式，再改组件样式，最后改页面样式，改完一个模块就测试；
- 要统一命名空间的规则，比如组件模块用components/xxx作为前缀，工具模块用utils/xxx作为前缀，不要随便起别名；
- 不要把所有样式都放在一个文件里，要按模块拆分，每个模块的样式不超过500行，太长的话要再拆分；
- 要检查循环引入，比如A引入B，B又引入A，这种情况会导致编译错误，要提前梳理依赖关系，避免循环引入；
- 要更新项目的Sass版本，确保用的是1.50.0及以上的Dart Sass，低版本可能不支持@use的部分特性。
五、文章总结
从@import迁移到@use，本质上是把样式从“无隔离的大杂烩”变成“有边界的模块化”，解决的是老项目样式混乱、加载慢、维护难的问题。迁移的过程不难，只要按步骤来，先梳理依赖，再逐个替换，然后测试，最后调整，就能平滑升级。
迁移的时候不要追求速度，要稳扎稳打，每改完一个模块就测试，遇到问题及时回滚，不要积累问题。另外，迁移后要养成模块化写样式的习惯，每个模块的样式独立，不要跨模块调用样式，这样项目才能一直保持好的维护性。
Comments