Less中无原生命名空间，需用嵌套选择器、命名约定和mixin模拟；推荐顶层类包裹+同名mixin组合，避免嵌套过深与CSS Modules冲突，核心是统一“mixin即API”约定。
Namespaces在Less中不是真正的命名空间，而是作用域模拟
Less本身没有像JavaScript模块或CSS Scoped那样原生的命名空间机制。namespace 关键字并不存在，所谓“Namespaces”实际是通过嵌套选择器 + 命名约定 + .mixin 封装来模拟的。直接写 ui.button() { ... } 会报错——Less不支持点号调用语法。真正可行的是用嵌套规则块配合带前缀的mixin名，比如 .ui-button() 或 .ui .button()，但后者容易污染全局选择器。
用嵌套类名 + mixin组合实现逻辑分组
核心思路是：把工具类按功能域组织进一个顶层类名下，再用 mixin 提供可复用的样式逻辑。这样既避免全局污染，又保持调用直观。
- 定义一个顶层容器类（如
.ui），它本身不生成CSS，仅作作用域包裹 - 所有子工具类（
.button、.input）都写在.ui下，形成.ui .button这样的选择器 - 同时提供同名 mixin（如
.ui-button()），方便在其他地方复用样式逻辑，不依赖HTML结构 - 注意：如果项目需支持CSS-in-JS或动态主题，优先用 mixin 而非嵌套类，否则无法脱离DOM结构复用
.ui {
& .button {
padding: 8px 16px;
border-radius: 4px;
}
}
.ui-button() {
padding: 8px 16px;
border-radius: 4px;
}
避免嵌套过深导致选择器权重失控
Less嵌套容易写出 .ui .form .field .input:focus 这种4级选择器，后续覆盖成本高，且和BEM规范冲突。真实项目中，建议：
- 嵌套最多2层（如
.ui .button可以，.ui .form .input就该拆） - 用
@import按功能拆文件（ui-buttons.less、ui-layout.less），每个文件只暴露1个顶层命名空间类或 mixin 集合 - 给 mixin 加参数控制变体，而不是靠更多嵌套层级区分状态，例如：
.ui-button(@variant: default)而非.ui .button.is-primary - Webpack或Vite环境下，确保
less-loader的javascriptEnabled为false（默认），否则可能意外启用危险的JS求值，破坏构建稳定性
与CSS Modules或PostCSS共存时的兼容要点
如果项目已用CSS Modules，Less Namespaces会和自动哈希类名冲突——.ui .button 编译后变成 .ui_xxx .button_yyy，失去语义关联。这时应放弃嵌套类写法，纯用 mixin：
立即学习“前端免费学习笔记（深入）”；
- 把所有工具样式写成无副作用的 mixin，例如
.text-truncate()、.visually-hidden() - 在组件Less文件中显式调用：
.text-truncate();，由CSS Modules处理最终类名 - 用
@plugin引入postcss-less插件时，注意它不解析 mixin，只处理变量和嵌套，复杂逻辑仍要靠Less原生编译 - VS Code中安装
Less IntelliSense插件，能提示已定义的 mixin 名，但对嵌套类名无补全能力
真正难处理的不是怎么写Namespaces，而是团队是否统一接受“mixin即API”的约定——一旦有人直接写 .ui-button 类到HTML里，就等于把样式耦合进了模板，后续迁移成本陡增。
