Less不提供限制优先级的语法，控制优先级本质是控制编译后选择器的结构和长度：越短越扁平，权重越低，越易被覆盖。
Less本身不提供“限制优先级”的语法机制，所谓控制优先级，本质是控制编译后选择器的结构和长度——越短、越扁平的选择器，权重越低，越容易被后续规则覆盖。
为什么嵌套层级直接决定CSS权重
Less嵌套不是逻辑封装，而是字符串拼接。写三层嵌套 .card { .header { .title { color: red; } } }，编译出来就是 .card .header .title，这是一个权重为 0,0,3,0 的后代选择器。而直接写 .card__title 权重只有 0,0,1,0。浏览器匹配时前者要逐级查找，覆盖时后者用 .card__title:hover 就能轻松升级，前者可能得靠 !important 硬顶。
- 每多一层嵌套，选择器中类名数量+1，权重数字就+1（第三位）
-
&不改变权重，但决定是否生成新类名：写&__body→.card__body（低权）；写.body（无&）→.card .body（高权） - 伪类如
&:hover编译为.card:hover，权重仍为 0,0,1,1，比.card .item:hover（0,0,2,1）低一级
哪些嵌套写法会意外拉高权重
看似省事，实则埋雷。常见失控写法：
-
.btn { .icon { margin-left: 4px; } }→ 编译为.btn .icon，权重翻倍，且无法用.icon单独覆盖 -
.modal { &.is-open { .overlay { opacity: 0.8; } } }→ 编译出.modal.is-open .overlay，四层深度，权重 0,0,3,0 -
ul { li { a { &:hover { text-decoration: underline; } } } }→ul li a:hover，权重 0,0,3,1，远高于a:hover - 在媒体查询里套全量嵌套：
@media (max-width: 768px) { .nav { .item { display: block; } } }→ 每个.item规则都重复带前缀，体积和权重双膨胀
不用 !important 也能压住高权选择器的实操办法
与其用 !important 掩盖问题，不如从源头降低权重或提升覆盖精度：
立即学习“前端免费学习笔记（深入）”；
- 把深层嵌套拆成 BEM 式扁平类：
.card+.card__header+.card__header-title，全部独立定义，权重恒为 0,0,1,0 - 用
@at-root跳出嵌套写同级规则：.card { @at-root .card--compact { padding: 4px; } }→ 输出.card--compact，不带父级前缀 - 覆盖时用更具体但不过度嵌套的选择器：想改
.list .item .content p，别写.list .item .content p em，改用p em+ 局部类.content-em - 借助属性选择器降权：
[data-comp="card"] .title权重 = 0,0,2,0，比.card .header .title（0,0,3,0）低，且语义清晰
检查与卡点：如何确认你的选择器没失控
别等上线才发现权重爆炸。本地开发就能快速验证：
- 编译后打开 CSS 文件，搜索空格数：用文本编辑器查
{前的空格，超过 6 个基本对应 4 层以上嵌套 - 命令行扫长选择器：
npx lessc components/card.less | grep -E "\.[a-z]+(\s+\.[a-z]+){3,}"，命中即表示含 4 个及以上类名的后代链 - VS Code 装 Less IntelliSense，嵌套超 3 层自动标黄；配合
postcss-selector-max-specificity在构建阶段拦截权重 > 0,2,0 的规则 - 真遇到必须高权的场景（如主题切换），用顶层 data 属性控制：
html[data-theme="dark"] .card__title，比.theme-dark .card .card__body .card__title清晰可控得多
真正难的不是写出高权选择器，而是意识到它正在悄悄破坏样式可维护性——尤其当多个开发者在不同文件里往同一块嵌套里塞规则时，权重会像雪球一样滚大，最后谁都不敢动。
