less的#namespace语法仅作mixin容器，不生成css或样式隔离；真正模块化需用@ns变量配合&拼接生成bem类名（如.ui-button__primary），并依赖html顶层类名约定。
Less 的 #namespace 语法本身**不组织设计系统，也不隔离样式**——它只是 mixin 容器，编译后不生成任何 CSS；真正起作用的是 @ns 变量 + & 拼接 + HTML 约定的顶层类名。
命名空间不是作用域，而是前缀拼接机制
写 #ui-button { .primary { color: blue; } }，编译后**完全不输出任何 CSS**；只有显式调用如 div { #ui-button > .primary(); } 才会生成 div { color: blue; }，且不带任何前缀。这和“模块封装”毫无关系，反而容易让人误以为样式已隔离，上线后引发全局污染。
真正可控的模块化方式是：
- 定义变量：
@ns: ~".ui-button";（波浪号~不可省，否则被当字符串） - 用
&紧贴拼接：@ns { &__primary { color: #007bff; } &--large { padding: 12px 24px; } } - 编译结果就是干净的 BEM 类名：
.ui-button__primary、.ui-button--large
HTML 必须手动加顶层类名，否则样式失效
上面生成的 .ui-button__primary 是独立类名，不依赖父选择器；但它要生效，HTML 中必须有对应 class：
-
<button class="ui-button__primary">Click</button>✅ 直接匹配 -
<div class="ui-button"><button class="ui-button__primary">Click</button></div>✅ 也 OK（BEM 允许嵌套容器） -
<button class="ui-button__primary">Click</button>但没加ui-button类？✅ 依然生效 —— 因为它是平级类名，不是后代选择器 - 错误做法：
.ui-kit { .button { ... } }→ 编译成.ui-kit .button，必须 DOM 有class="ui-kit"包裹才生效，动态弹窗等场景极易漏加
混入（mixin）封装组件时，参数 + 守卫比嵌套命名空间更可靠
想让按钮支持 primary/secondary 变体，别写一堆 #button > .primary() 调用，而应：
- 把 mixin 定义在外部文件（如
mixins/buttons.less），用@import (reference)引入，避免重复输出 - 用守卫控制分支：
.button(@type: default) when (@type = primary) { background: @primary-color; } - 调用时统一写：
.ui-button__primary { .button(primary); }，生成的 CSS 自动带目标类名，无权重膨胀 - 禁止在命名空间块内定义变量（如
@primary-color），它们该放在variables.less中全局管理
嵌套超过两层时，#namespace 反而掩盖结构问题
看到 #modal > #overlay > #content > .header 这种调用链，说明组件职责已经混乱。Less 的 #namespace 不限制嵌套深度，但浏览器 DevTools 里源码定位会严重错乱，CSS 选择器权重也会飙升到 0,3,0,1，覆盖难度陡增。
更务实的做法是：
- 放弃模拟 DOM 层级，改用 BEM 平级命名：
.modal__overlay、.modal__content、.modal__header - 所有样式收口在单层
.modal命名空间下：.modal { .modal__overlay { ... } .modal__content { ... } } - 第三方库冲突时，
#namespace完全无效；真正有效的是类名唯一性（如加项目前缀myapp-modal__overlay）和加载顺序控制
最常被忽略的一点：命名空间类名是否加在 HTML 上，不是“可选优化”，而是“开关级前提”——漏加一个 class="ui-kit"，整套组件样式就归零；而用 @ns + & 生成的类名，只要 class 写对，就一定生效，不依赖容器结构。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
