Less提升可维护性需规避隐性陷阱：变量冲突不报错、类型混用致运算崩坏、@import顺序影响主题切换；嵌套过深抬升特异性，Mixin参数设计不当易埋雷；关键在统一命名、限嵌套深度、规范Mixin文档与路径约束。
可以，但前提是用对方式、避开隐性陷阱。单纯引入 .less 文件不自动提升可维护性，变量乱定义、嵌套过深、@import 路径混乱反而会让团队协作和后续维护更痛苦。
变量不是写一次就万事大吉
Less 的 @primary-color 看似省事，但实际项目里容易踩坑：
- 变量名冲突不报错：两个
@import文件都定义了@spacing-sm，后加载的会静默覆盖前一个，调试时样式“莫名变矮”很难定位 - 值类型混用：把
@z-index-modal: 1000和@z-index-overlay: @z-index-modal + 1写在一起看似聪明，但一旦@z-index-modal被改成字符串（比如加了单位），整个运算崩掉且无提示 - 主题切换依赖顺序：深色主题文件必须在基础变量之后
@import，否则覆盖无效；构建工具若未保证导入顺序，npm run build出来的 CSS 就是错的
嵌套规则让结构清晰，也容易生成冗长选择器
写 .card { &__header { font-size: 16px; } } 确实比手动拼 .card__header 直观，但要注意：
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 三层以上嵌套（
.page .section .block .item）会导致编译后选择器过长，CSS 特异性飙升，后续用!important或更高权重选择器覆盖就成了惯性操作 -
&:hover里再嵌套属性（如&:hover { color: @hover-color; transition: color 0.2s; }）没问题，但若在里面又写&__icon，就等于生成.card:hover .card__icon—— 这种耦合反而降低组件复用能力 - 嵌套不等于 HTML 结构绑定：组件内部 DOM 变动时，对应 Less 嵌套必须同步改，否则编译出的选择器根本匹配不到元素
Mixin 封装逻辑，但参数缺失或默认值不合理会埋雷
.flex-center() 这类通用 mixin 很好用，但常见问题集中在参数设计上：
立即学习“前端免费学习笔记（深入）”；
- 没设默认值：调用
.flex-center()时漏传@direction，编译直接失败，而错误信息只显示 “undefined variable”，不指明是哪个 mixin 哪个参数 - 参数过多难记：一个
.button-style(@bg, @color, @border, @radius, @hover-bg, @active-bg)写满 6 个参数，开发者每次都要查文档或翻源码，实际使用率反而下降 - 副作用隐藏：某个
.reset-input()mixin 除了清空边距，还悄悄加了outline: none，导致可访问性审查失败，但没人意识到这是 mixin 引入的
真正提升可维护性的关键不在“用了 Less”，而在约束力：统一变量命名规范、限制嵌套深度为两层、所有 mixin 必须带文档注释和最小可用示例、@import 路径全部用相对路径并禁止循环引用——这些规则比语法本身更影响长期成本。
