@import顺序即css层叠顺序；less在编译期将所有@import提升至文件顶部，按书写顺序拼接内容，后导入的同权重规则自然覆盖前者，须严格按“重置→变量/mixin→基础组件→业务组件→页面定制”分层导入入口文件。
Less的@import顺序就是CSS层叠顺序
Less不运行时加载，所有@import在编译期被提升到文件顶部、按书写顺序拼接——最终CSS里哪条规则在后面，就真能覆盖前面同权重的选择器。
常见错误是把@import "components/button.less";写在@import "base/reset.less";前面，结果按钮样式先出现、重置规则后压上去，按钮反而没了边框或内距。
- 入口文件（如
index.less）头部集中写@import，严格按「重置 → 变量/mixin → 基础组件 → 业务组件 → 页面定制」分层 - 禁止在
button.less里再@import "mixins.less"——依赖关系会失控，编译后样式块可能插进不该在的位置 - 用
@import (reference)引入只提供变量和mixin的文件，避免重复输出CSS - 别靠文件名排序（比如
_01-base.less），Less根本不识别这种命名
嵌套不等于作用域隔离，&必须手动收束
写.card { .title { color: red; } }，编译出来是.card .title，不是.card__title。一旦页面其他地方也有.title，照样被影响。
嵌套本身放大选择器权重，还容易漏掉&导致意外全局污染——比如写.card { > .content { ... } }，少了个&，就会生成一条独立的> .content规则，直接匹配整个文档里的.content。
- 要用BEM风格：写
.card { &__title { color: red; } }，输出.card__title，物理级隔离 -
&:hover这类展开要谨慎，父类名一改，所有子状态全失效；只对明确属于该组件的交互才用 - 三层以上嵌套（如
.a { .b { .c { ... } } }）会生成.a .b .c，特异性过高，后期几乎无法局部覆盖
z-index必须用语义化变量统一管理
散落各处的z-index: 999或z-index: 1000是层叠冲突的根源。Modal盖不住Dropdown？大概率是两人各自写了魔法数字，谁先编译谁赢。
更麻烦的是，写了z-index: @z-modal却还是被盖住——父容器触发了新层叠上下文（比如加了transform或opacity: 0.99），整个子树被锁死在局部层级里。
- 新建
variables.less，定义@z-toast: 300;、@z-dropdown: 500;、@z-modal: 900;，相邻值至少差10，留插入余地 - 变量名绑定UI角色（
@z-drawer），不用@z-high这种模糊词 - 检查层叠上下文边界：Chrome开发者工具开「Layers」面板，看是否父级悄悄创建了新堆叠上下文
- 需要动态读取时，不能只导出
--z-modal: 900，还得显式写.modal { z-index: var(--z-modal); }
!important不是解药，而是债务加速器
!important在Less里不会因为嵌套就变弱或变强，它只看最终输出的选择器权重。你加一个，别人就得加两个，或者硬塞ID选择器，恶性循环。
多人协作中，A在.btn { color: blue !important; }，B想调文字颜色，只能也加!important或写#app .btn来提权——这不是覆盖，是互相绑架。
- 真正该做的是提前约定层级顺序：基础样式→布局组件→业务组件，靠
@import顺序和命名压制 - 重置文件里绝不用
!important锁死可覆盖属性（比如button { color: inherit !important; }） - 需要强覆盖时，优先提高选择器特异性（如
.btn.btn-primary），而不是堆感叹号
@import的“提升”行为和嵌套中&的缺失——它们不报错，但会悄无声息地把样式规则塞到意想不到的位置，或者让本该局部的样式变成全局污染。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
