Sass 本身不提供 CSS 样式版本化管理能力，真正的版本控制必须由 Git 等 SCM 工具完成；@use 和 @forward 仅负责编译期的模块隔离与接口契约，不识别语义化版本号，路径指向本地文件而非包管理器版本。
Sass 本身不提供 CSS 样式版本化管理能力，它只是编译器；真正的版本控制必须交由 Git 等 SCM 工具完成，而 Sass 的模块机制（@use、@forward）仅负责在编译期隔离和透传样式逻辑——不是版本，而是接口契约。
为什么不能靠 @use "vars@1.2.0" 这类写法做版本管理
这是常见误解。Sass 的 @use 路径是文件系统路径，不是包管理路径：@use "src/styles/vars" 指向的是本地 _vars.scss 文件，不识别语义化版本号。npm 或 pnpm 的 ^1.2.0 版本范围只影响 node_modules 中的包安装，Sass 编译器对此无感知。
常见错误现象：
- 团队成员本地
node_modules/@design-system是 v1.1.0，但 CI 构建用的是 v1.3.0，$spacing-md含义已变，却没报错 - 误以为
@use "lib/button"自动拉取最新版，结果实际引用的是旧 symlink 或缓存副本 - 发布新版本后忘记更新文档中的变量名变更，下游项目照常编译通过，但视觉出错
Git + 目录结构才是真实可行的版本化落地方式
把设计系统或基础样式库当作独立 Git 仓库维护，每个 commit/tag 对应一个明确的样式“版本”。Sass 层面只需保证导入路径稳定、接口清晰。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 样式库仓库根目录放
index.scss，内部统一@forward所有可暴露模块，并用with控制默认值：@forward "vars" with ($radius-sm: 4px !default); - 应用项目中通过 submodule 或 npm package 引入样式库，路径固定为
@use "@design-system/index" as ds;—— 此时 Git tag 或 package.json 的"version"就是样式版本 - 禁止在应用项目里直接
@use "node_modules/@design-system/vars"：路径太深、易断裂，且绕过入口封装，丢失@forward with提供的兼容层 - CI 流程中增加检查：构建前运行
npm ls @design-system并比对package-lock.json中的 resolved 字段，确保版本锁定生效
如何让版本升级不破下游？靠 @forward 做兼容性封装
版本迭代时，真正危险的不是新增功能，而是变量重命名、@mixin 参数调整、移除私有成员。这些必须由 @forward 显式控制暴露边界。
示例场景：
- v1.5.0 把
$color-link改名为$color-interactive，但要在@forward "vars"中保留旧名映射：@forward "vars" as old-*;，再手动导出$old-color-link: $color-interactive; - v2.0.0 移除了
@mixin fluid-type()，改用 CSSclamp()内联；可在入口index.scss中@use "utils" as u;并重新定义@mixin fluid-type() { @include u.clamp-text; }，维持调用签名 - 所有
@forward必须加hide或as显式声明，避免隐式透出内部实现（如_private-mixins.scss）
最易被忽略的一点：Sass 模块的“版本”不在代码里，而在 package.json 的 version 字段和 Git tag 的对应关系中；@use 和 @forward 只是让你能安全地消费那个版本——它们不管理版本，只尊重版本。
