Less中@import顺序直接影响样式生效，因为其按顺序解析、合并作用域并覆盖变量和规则；后导入文件可覆盖先导入的同名变量、混合及选择器，前提是未使用(reference)或(inline)修饰。
Less中@import顺序为什么直接影响样式生效
因为Less的@import不是简单拼接文件，而是按顺序解析、合并作用域、覆盖变量和规则。后导入的文件能覆盖先导入的同名变量、混合（.mixin）甚至选择器，但前提是它们在同一个编译上下文中——比如没加(reference)或(inline)修饰。
- 如果
@import "vars.less";放在@import "button.less";后面，而button.less里用了@primary-color，那它用的是vars.less里定义的值；反过来就可能报variable @primary-color is undefined -
@import (less) "reset.css";会把CSS当Less处理（允许其中写@media嵌套），而@import (css) "reset.css";则原样输出——类型错配会导致意料外的编译结果 - 用
@import (reference) "mixins.less";时，里面的.btn()不会被输出，只供其他文件调用；但一旦某处忘了加(reference)，整个mixins内容就重复输出一遍
Less注释怎么写才不破坏CSS合法性
Less只认/* */，//会被原样输出到CSS里，导致非法样式或空白行。比如写// 主按钮悬停色，编译后变成一行孤立的// 主按钮悬停色，浏览器直接忽略，还可能干扰压缩器判断。
-
/* */注释在编译阶段就被完全剥离，不进最终CSS，也不占体积 - 嵌套在
.mixin内部的/* */会保留在调用处生成的CSS上方，影响压缩结果（比如被误判为可删空行） - 媒体查询、伪类嵌套块里的
/* */位置要小心：写在规则末尾（如color: red; /* 覆盖默认色 */）才安全；写在属性名前（如/* 覆盖默认色 */ color: red;）会导致注释飘到上一个规则后面
嵌套超过3层会带来什么隐性代价
嵌套本身不难，但写多了容易生成过深的选择器、重复的父级引用，或者误以为嵌套能替代BEM类名逻辑。Less嵌套本质是语法糖，编译后仍生成标准CSS，所以它解决的是「人看代码」的问题，不是「浏览器渲染」的问题。
- 嵌套超过3层（如
.a { .b { .c { .d {} } } }）会显著增加选择器权重，也难维护，建议拆成独立类或用BEM命名收口 -
@media (max-width: 768px) { .nav { li { a {} } } }这类写法编译后生成@media (max-width: 768px) .nav li a，调试时定位困难，且易被更高权重规则覆盖 - 用
&__header替代.header嵌套，确保输出类名扁平、可预测；避免依赖缩进模拟DOM深度
命名参数对Mixin调用可读性的真实影响
命名参数让.mixin()调用不再靠猜顺序：定义时必须用@name: value声明默认值，调用时可自由指定参数名如.button(@size: large, @theme: brand)，支持混用但不推荐，适用于语义差异大或多维组合场景。
立即学习“前端免费学习笔记（深入）”；
- 必须在定义时用
@name: value语法声明，默认值不是可选，而是强制要求——没默认值又不传参，编译直接报variable @xxx is undefined - 调用时用
@name: value形式，比如.button(@size: large, @theme: brand)，哪怕把@theme写在前面也完全合法 - 命名参数不能解决“参数太多”的问题，只是让调用更安全；真有6个以上参数，说明Mixin职责过重，该拆了
- 命名参数配合
when守卫才能防坑，光写@shadow: false当默认值不行——box-shadow: false是无效CSS
真正决定可读性的，不是某一行嵌套或一个变量名，而是每次修改前你是否清楚这个@import背后有没有循环依赖、这个/<em> </em>/是否还在解释“为什么”而不是“写了什么”、这个&.is-active的注释是否还能让人三分钟内定位到对应DOM节点。
