跨项目复用Less样式的核心是变量作用域隔离与安全覆盖：所有基础变量须带!default声明于公共库，各项目在入口文件中显式赋值覆盖（不加!default），严格控制@import顺序；Mixin需加前缀、禁裸名、禁直接输出CSS；主题切换应依赖CSS自定义属性而非Less变量。
跨项目复用Less样式，核心不是“怎么导出”，而是“怎么隔离变量作用域、避免隐式覆盖、让每个项目能安全覆盖又不污染全局”。直接把 variables.less 拷过去改，不出三个月就会出现某个项目升级后按钮变蓝、另一个项目表单边框消失的问题。
如何让不同项目共用一套变量但互不干扰
关键在 !default —— 它不是“可选赋值”，而是“仅当未定义时才生效”的守门机制。所有基础变量必须带 !default，且只在项目级入口文件里做最终赋值。
-
@primary-color: #007bff !default;放在公共库的variables.less里，它只是占位，不锁定值 - 每个项目自己的
src/styles/overrides.less中写：@primary-color: #2563eb;（不加!default），这行会覆盖公共库的默认值 - 禁止在组件文件（如
button.less）里重新声明@primary-color，否则导入顺序一变，值就不可控 - Webpack 构建时，确保项目级
overrides.less在公共库variables.less之后被@import，顺序错了!default就失效
为什么不能直接 npm link 公共 Less 包
Less 不是 JS，npm link 后路径解析会崩。比如公共包里写 @import "mixins/border-radius"，项目里配置了 paths: ["src/styles"]，但没配公共包的 node_modules/@myorg/styles 路径，编译直接报 Cannot find module。
- 必须在
less-loader的lessOptions.paths中显式加入公共包路径：path.resolve(__dirname, 'node_modules/@myorg/styles') - Vite 用户注意：
lessOptions.paths是数组，多个路径要全列出来，不能只写一个 - 绝对别在公共包内部用
@import "../core/variables"这种相对路径——它在被其他项目引用时，基准目录是调用方文件位置，不是包自身
Mixin 泄漏比变量更危险，怎么防
一个没加命名空间的 .clearfix() 被两个项目同时 import，其中一个项目升级后加了 .clearfix() { display: flow-root; }，另一个项目还没升级，结果所有浮动清除逻辑突然失效——因为新规则覆盖了旧规则，而你根本没感知到。
立即学习“前端免费学习笔记（深入）”；
- 所有公共 Mixin 必须加前缀，比如
.mylib-clearfix()，杜绝裸名冲突 - 禁止在公共 Mixin 内部直接输出 CSS（即不带选择器的规则块），例如：
.mylib-text-ellipsis() { overflow: hidden; ... }是安全的；但.mylib-reset { margin: 0; }是危险的，它会无条件注入全局样式 - 公共包的
index.less只暴露@import声明，不包含任何实际样式输出；项目必须显式@import "mylib/mixins"才能使用，不能靠父级间接引入
主题切换在跨项目场景下为何容易失效
当 A 项目用 !default 覆盖了 @theme-mode: dark，B 项目却依赖 @theme-mode 的原始值生成 CSS 类名（如 .theme-@{theme-mode}），构建出来的类名就是 .theme-dark，但 B 项目实际运行时是 light 模式——变量在编译期已固化，无法运行时响应。
- 运行时主题切换必须靠 CSS 自定义属性（
var(--theme-color)）+ JS 控制，Less 变量只用于构建期静态定制 - 如果真要用 Less 实现多主题，每个主题必须单独编译一份 CSS 文件（如
theme-light.css/theme-dark.css），由 HTML<link>动态切换，而不是靠一个变量控制全部 - 公共包里的 Mixin 如果含主题分支逻辑（如
.mylib-button() when (@theme-mode = dark) { ... }），必须确保@theme-mode在项目入口处被明确赋值，且不被子项目意外重置
最易被忽略的一点：跨项目共享的 functions.less（比如颜色处理函数）一旦修改，所有依赖它的项目都得重新编译——它不像 JS 那样有 tree-shaking，Less 函数是文本替换，哪怕某项目根本没调用 lighten()，只要 import 了文件，就得参与编译。所以函数库要足够稳定，小版本更新也应视为 breaking change。
