less 不强制 bem 规范，需人工约定与工具辅助；class 名须 kebab-case、语义化、无驼峰/下划线/数字开头；变量和 mixin 命名解耦 css 类名；嵌套限 3 层内且仅用于状态；修饰符须平级定义以支持自由组合；html 必须显式书写完整 class 名。
Less 本身不定义 CSS 命名规范，它只是提供语法支持；真正的 BEM 规范必须靠人写、靠约定守、靠工具（如 lessc --lint）辅助检查——没有“自动合规”的捷径。
class 名必须用 kebab-case + 语义化单词组合
所有 class 名禁止驼峰、下划线或数字开头，只允许小写字母、数字、中划线（-），且必须表达组件职责而非 DOM 结构。
-
.card✅（块 Block）；.card-header✅（元素 Element）；.card--featured✅（修饰符 Modifier） -
.CardHeader❌（驼峰）；.card_header❌（下划线）；.1st-item❌（数字开头）；.main-content-wrapper❌（过长、无必要嵌套语义） - HTML 中必须严格对应：
<div class="card card--featured"> <h2 class="card__title">，不能靠嵌套路径推导类名 <h3>Less 变量和 mixin 命名要与 CSS 类名解耦</h3> </h2> <p>变量和 mixin 是开发时的抽象工具，不是 CSS 输出的一部分，命名不必强求跟 class 一致，但需内部统一、可读性强。</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill7761" title="Article To Html"><img src="https://img.php.cn/upload/skill/000/000/081/179168408018805.jpg" alt="Article To Html" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill7761" title="Article To Html" class="overflowclass">Article To Html</a> <p class="overflowclass">文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。</p> </div> <a rel="nofollow" href="/xiazai/skill7761" title="Article To Html" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div> <ul> <li>变量用 <code>@开头 +-分隔：@color-primary、@spacing-md，禁止@primaryColor - mixin 用
.开头 +-分隔：.btn-reset()、.text-truncate()，形参缩写清晰，如.border(@w: 1px; @c: @gray-300) - 不要为每个 class 写一个同名 mixin：
.card() { .card { ... } }是冗余反模式；mixin 应封装逻辑（重置、响应式、状态），而非搬运类名
嵌套层级必须控制在 3 层以内，且仅用于状态组合
嵌套不是为了“少敲几遍 class”，而是为了表达明确的上下文关系；超过 3 层就该拆成独立 BEM 类，否则编译出的选择器权重失控、调试困难。
- ✅ 合理：
.btn { &--primary { &:hover { ... } } }→ 编译为.btn--primary:hover，权重稳定 - ❌ 危险：
.modal { .overlay { .content { .header { h1 {} } } } }→ 编译为.modal .overlay .content .header h1，权重飙升且无法复用 - 媒体查询别塞进嵌套里：
.card { @media (max-width: 768px) { .card__title { ... } } }会导致重复输出，应提至顶层或用响应式 mixin 封装
BEM 修饰符必须能自由组合，不能依赖嵌套顺序
真实项目中常出现 .card--featured.card--loading .card__title 这类组合，如果修饰符定义在嵌套深处（比如 .card { &--featured { .card__title {} } }），就会丢失组合能力。
- 正确做法：所有修饰符都平级定义，用
&--modifier直接拼接，确保可叠加：.card--featured.card--loading .card__title能命中预期样式 - 错误陷阱：
.card { &--featured { &__title {} } }→ 只匹配.card--featured .card__title，一旦加了.card--loading就失效 - 真正难的是 HTML 层面的配合：开发者必须自觉写
class="card card--featured card--loading"，而不是靠 Less “生成”它
最易被忽略的一点：BEM 规范的生命力不在 Less 语法多花哨，而在团队能否坚持「一个元素一个类」「修饰符不嵌套」「HTML 类名即契约」——编译器不会替你 enforce 这些，它只忠实地把 & 和 @{} 翻译成 CSS。
