modifyVars必须配合独立编译上下文使用，因其仅作用于本次render的顶层作用域，不合并已有变量池，未显式传入的变量（如@spacing-xs）将报undefined错误，需一次性传全所有依赖变量。
Less 3.0 的重写功能（modifyVars + render API）不是为了让你“动态换色”，而是让 CSS 库开发者能真正交付可配置、可复用、不污染宿主环境的样式包。
为什么 modifyVars 必须配合独立编译上下文使用？
很多人调用 less.render() 时直接传入全局变量，结果发现 @primary-color 被覆盖后，其他未显式声明的变量（比如 @border-radius）突然变成 undefined —— 这不是 bug，是 Less 3.0 的设计前提：变量必须显式传入，否则视为缺失。
-
modifyVars不会“合并”到已有变量池，它只作用于本次编译的顶层作用域 - 如果源文件依赖
@spacing-xs但你没在modifyVars里提供，编译直接报错：variable @spacing-xs is undefined - 正确做法：把所有可能被覆盖的变量（含默认值）一次性传全，例如：
{ '@primary-color': '#1890ff', '@border-radius': '4px', '@font-size-base': '14px' }
render 的 paths 和 filename 参数决定 import 是否可预测
库开发者常犯的错误是：把 button.less 单独丢给用户 render，结果用户 @import "mixins.less" 失败——因为路径解析失败，不是文件不存在，而是 Less 默认以当前工作目录为根，而库内部的相对路径（如 @import "../mixins/border.less"）根本找不到。
- 必须显式传
filename: 'node_modules/my-ui/lib/button.less'，否则@import全部按空字符串解析 -
paths要指向库的base/或mixins/目录，不能只写node_modules/my-ui，否则子目录下的嵌套@import仍会断链 - 禁止在库代码里用
@import (reference)隐式加载依赖，它绕过paths控制，导致用户无法拦截或替换
为什么 sourceMap 在库分发时必须设为 inline 而非 file？
用户项目里开启 sourcemap 后，Chrome DevTools 点击 CSS 行跳转到 button.less，结果打开的是本地 /tmp/less-xxxxx.less —— 这不是路径错了，是 Less 3.0 默认生成外部 map 文件，而 npm 包里不可能附带临时文件。
立即学习“前端免费学习笔记（深入）”；
-
sourceMap: { sourceMapFileInline: true }才能让 map 内联进 CSS，确保跳转精准指向原始lib/button.less - 若用
sourceMapFile，必须额外打包 .map 文件并保证部署路径一致，这对 CDN 分发的 UI 库几乎不可控 - 调试时若看到
debug: @color注释没出现在输出 CSS 里，说明你用了旧版 less-loader 或没开javascriptEnabled: true
最易被忽略的点：Less 3.0 的重写能力只对“一次完整编译”有效。它不支持运行时热替换变量，也不维护跨多次 render 的变量状态。库的 theme 切换必须每次重新编译整个入口文件，而不是局部 patch —— 这不是限制，是刻意为之的隔离设计。
