Sass 的 @while 不支持递归布局，因其仅为编译时循环，无法实现运行时条件判断或触发 CSS 层叠逻辑；多级嵌套选择器（如 .menu > .menu > .menu）属静态规则生成，非控制流递归。
为什么不能用 @while 做“递归布局”
Sass 的 @while 是纯编译时的循环，它不支持运行时条件判断，更无法触发 CSS 层叠逻辑的“递归”。所谓“多级层叠 CSS”，比如 .menu > .menu > .menu 这类选择器嵌套，本质是静态规则生成问题，不是控制流递归。你写 @while $i ，Sass 确实能输出 5 层嵌套选择器；但一旦层级依赖 DOM 结构动态深度（比如菜单实际只有 3 层，但编译时你设了 5），就会产出冗余、不可维护、甚至覆盖出错的 CSS。
@while 生成嵌套选择器的正确姿势
它只适合层级明确、数量固定的场景，比如设计系统中预设的最多 4 级下拉菜单、或 z-index 分层栈（$z-overlay, $z-modal, $z-tooltip…）。关键不是“能不能写”，而是“该不该让编译器替你猜结构”。
- 用
$level变量控制上限，别用max-depth这类模糊词 - 每轮循环必须修改循环变量，否则会死循环（Sass 编译直接报错：
Maximum call stack size exceeded） - 避免在
@while内部调用函数返回选择器字符串——Sass 不支持运行时拼接选择器，只能用&或@at-root配合插值#{}
示例：生成 1~4 级子菜单定位偏移
$i: 1;
@while $i <= 4 {
.menu--level-#{$i} {
left: $i * 16px;
}
$i: $i + 1;
}真正需要“动态层级”的时候，该换什么思路
CSS 本身没有递归，但现代方案有更稳的替代路径：
立即学习“前端免费学习笔记（深入）”；
- 用
:is()或:where()聚合多层选择器，比如.menu :is(.menu, .menu .menu, .menu .menu .menu) { … }—— 浏览器原生支持，无需 Sass 编译 - 用 BEM 的修饰符约定（
.menu__item--sub,.menu__item--sub-sub），靠 JS 控制 class，CSS 只写两到三级固定规则 - 放弃“全自动生成”，改用 mixin 封装常用嵌套模式，比如
@mixin menu-nested($depth: 2)，显式调用，不隐藏复杂度
强行用 @while 模拟“无限递归”，只会把构建时错误拖到运行时难排查——比如某层 margin 被意外覆盖，你得翻 20 行生成 CSS 才发现是第 3 轮循环里漏写了 !important。
兼容性和性能的隐形代价
所有 @while 生成的嵌套选择器，都会在编译后变成真实 CSS 规则。层级越多，CSS 文件体积增长是非线性的，而且浏览器解析长链选择器（如 .a .b .c .d .e）比单类名慢得多，尤其在低端设备上会卡住样式计算。
- Sass 3.5+ 支持
@while，但旧版（如 Dart Sass 1.0 之前）可能报Undefined operation错误 - 生成的选择器优先级会随层级升高而暴涨，容易和 utility-first 框架（如 Tailwind）冲突
- Source map 映射会变模糊——你看到的报错行号，可能是循环体第 1 行，但实际问题出在第 3 次迭代的插值逻辑里
最常被忽略的一点：当设计师临时加一级菜单，你得改 Sass 变量、清缓存、重新构建，而用 JS 动态加 class + 精简 CSS，反而更敏捷。生成器越“全自动”，后期越不敢动。
