Less通过变量和Mixin解耦值与行为，变量仅定义设计系统常量，组件样式用Mixin封装；CSS转Less需用postcss-less渐进转换，calc()加~""包裹；模块化用@import (reference)防重复；定位冲突靠注释标记和命名空间。
Less变量和Mixin如何避免样式迁移时的全局污染
直接改原始CSS容易牵一发而动全身，Less里用@variables和.mixin()做抽象，本质是把“值”和“行为”从选择器里抽出来。但很多人把所有颜色、间距全塞进variables.less，结果换一套主题时发现按钮边框色没跟着变——因为@border-color被写死在某个组件内部了。
实操建议：
- 变量只定义设计系统级常量（如
@primary-color、@spacing-xs），不定义组件专属值（比如@button-border） - 组件专属样式用Mixin封装，例如
.button-style()里聚合边框、圆角、阴影逻辑，替换时只改Mixin调用参数 - 避免在Mixin里硬编码
@import路径，用相对路径+构建工具解析，否则迁移时@import "base/mixins"可能指向旧目录
如何安全地将原生CSS批量转为Less并保留浏览器兼容性
直接把.css后缀改成.less再加@import，大概率会触发编译报错或样式丢失——尤其是遇到:not(.foo)这种带括号伪类，Less默认解析器会把它当成函数调用。
常见错误现象：ParseError: missing closing ')' in ... 或生成的CSS里calc()表达式被错误插值。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 用
postcss-less而非lessc做渐进式转换，它能更好识别原生CSS语法边界 -
calc()必须用双引号包裹：写成width: calc(~"100% - 2*@spacing-md")，否则Less会提前计算 - 对IE11等老环境，禁用
strictMath: true选项，否则10px / 2这类除法会被拒绝编译
模块化拆分时，如何防止Less @import链过深导致构建失败
重构大项目时容易陷入“每个组件一个.less，每个.less都@import 'vars'”的循环，Webpack里Less loader可能爆栈，或者热更新时整页重刷。
性能影响明显：10个组件各自@import 'utils/breakpoints'，最终生成的CSS里会重复输出同一套媒体查询规则。
实操建议：
- 只在入口文件（如
app.less）中@import基础层（variables、mixins、reset），其他文件用@import (reference)引入，避免重复注入 - 用
// stylelint-disable-next-line less/no-extend临时绕过extend警告，但别真用:extend()跨模块继承，它会让依赖关系不可见 - 检查
node_modules/xxx/src/styles路径是否被意外@import——第三方库的Less源码往往没做tree-shaking，直接引用会拖垮编译速度
替换旧样式时，怎样用Less快速定位并隔离冲突选择器
新旧样式共存阶段，经常出现.btn { color: red; }和.button { color: blue; }同时生效，但开发者只改了.button的Less文件，忘了.btn还在某个遗留JS模板里动态插入。
关键点在于：Less本身不解决选择器作用域问题，它只是预处理器。
实操建议：
- 用
/* @replace-target */注释标记待替换的选择器，在构建脚本里grep定位，比肉眼扫快得多 - 给新模块加命名空间前缀，比如
.v2-button，并在Less里用&嵌套保证层级干净：.v2-button { &-primary { ... } } - 别依赖
!important压样式，它会让后续维护者无法用常规方式覆盖；真要强覆盖，用更具体的选择器，比如.legacy-wrapper .v2-button
最麻烦的不是语法转换，而是旧项目里那些没文档的CSS魔法数字、靠兄弟选择器实现的布局、还有用margin-top: -5px强行对齐的hack——这些没法被Less自动识别，得靠人眼+DevTools逐个打点验证。
