基于Sass 7-1架构为何不推荐在各单文件内单独导入依赖？

Sass 7-1架构依赖导入规则的背景与最优实践 #

旧规则的历史背景 #

你提到的「子文件不导入依赖、统一在入口按顺序导入」是Sass旧版@import体系下的行业遗留规范，核心原因有两个：

• 早期@import没有去重机制，重复导入同一份SCSS文件会导致最终编译的CSS出现冗余代码，甚至出现变量、混合宏被重复覆盖的问题，统一在入口按优先级排序导入可以完全规避这类问题。
• 7-1架构的设计初衷是把抽象层（变量、函数、混合宏）作为全局共享资源，统一管理依赖顺序可以实现全局配置的高效修改，比如要批量替换主题色，只需要在入口导入抽象层之前覆盖对应变量即可生效，不需要逐个修改子文件的导入逻辑。

旧规则的固有缺陷 #

你发现的问题完全成立：

• 子文件依赖隐式声明，新增入口时很容易漏导入前置依赖导致编译报错，项目规模越大、依赖层级越深，排查成本越高。
• 编辑器无法识别隐式依赖，会出现语法校验报错、代码补全失效的问题，开发体验很差。
• 子文件无法单独复用，必须完整配套整套全局导入规则，灵活性极低。

现行最优解决方案 #

Sass官方从2020年推出的@use/@forward模块系统已经完全解决了旧@import的缺陷，目前行业通用的优化方案是在保留7-1架构目录分层的前提下，调整依赖导入逻辑：

1. 所有子文件显式导入自身依赖
   每个组件/工具类文件都用@use导入自己需要的抽象层模块，@use自带去重机制，多次导入同一份文件只会加载一次，不会产生冗余代码。
2. 抽象层模块按功能拆分
   你提到的拆分变量文件的思路完全符合最佳实践，不需要维护巨型单一变量文件，可以按功能拆分出_variables-grid.scss、_variables-color.scss、_variables-typography.scss等独立模块，再通过抽象层入口文件abstracts/_index.scss用@forward统一导出所有模块，方便全局导入。
3. 入口文件不需要维护依赖顺序
   因为所有子文件已经声明了自身依赖，入口只需要导入需要的业务模块即可，不需要再按优先级排序导入抽象层文件。

改造后的代码示例

abstracts/_variables-grid.scss

$gutter-horizontal: 6rem !default; // 加!default标识允许外部覆盖变量

abstracts/_index.scss

@forward "variables-grid";
@forward "variables-color";
@forward "mixins";
// 其他抽象层模块统一导出

layout/_grid.scss

// 显式导入自身需要的依赖，as*表示不需要加命名空间直接使用变量
@use "../abstracts/variables-grid" as *;

.col-1-of-2 { 
  width: calc((100% - #{$gutter-horizontal}) / 2); 
}

main.scss

// 可以直接导入业务模块，不需要提前导入变量
@use "layout/grid";

// 如果需要覆盖默认变量，只需要在导入前定义同名变量即可
// $gutter-horizontal: 4rem;
// @use "layout/grid";

内容的提问来源于stack exchange，提问作者Napoleon