移动端多层级菜单不能只靠硬编码padding-left，因嵌套越深越难维护且需响应主题、字体、缩放；应使用css变量（如--indent-step）配合层级class（如.menu-item--level-2）和calc()动态计算缩进，避免attr()兼容性问题，并注意单位统一、overflow隐藏及动画同步。
移动端多层级菜单为什么不能只靠 padding-left 做缩进
直接写 padding-left: 20px 看似简单，但嵌套越深越难维护：第3级要40px、第4级60px……硬编码层级数会卡死后续迭代。更麻烦的是，缩进值还得随主题色、字体大小或缩放比例动态调整——这时候 calc() 和 CSS 自定义属性（变量）就不是“可选优化”，而是必须用的手段。
关键点在于：缩进量应与层级深度强绑定，且能被全局控制。
- 用
--indent-step变量统一定义每级缩进基准（比如16px） - 用
data-level="1"、data-level="2"等标记 DOM 层级，避免依赖 DOM 结构深度（防止伪类失效） -
calc(var(--indent-step) * (attr(data-level number, 1) - 1))是核心计算逻辑，但注意：attr()在 calc 中支持度有限，实际得换招
真正可用的 calc + 变量缩进方案：用 :nth-child 或 class 模拟层级
别碰 attr(data-level)——它在 calc() 里几乎不工作（Chrome 115+ 才开始实验性支持，Safari 完全不认）。稳妥做法是把层级“编译”进 class 名，比如 .menu-item--level-1、.menu-item--level-2，再配合 CSS 变量驱动缩进：
:root {
--indent-step: 16px;
}
<p>.menu-item--level-1 { padding-left: calc(var(--indent-step) <em> 0); }
.menu-item--level-2 { padding-left: calc(var(--indent-step) </em> 1); }
.menu-item--level-3 { padding-left: calc(var(--indent-step) <em> 2); }
.menu-item--level-4 { padding-left: calc(var(--indent-step) </em> 3); }
</p>
这样既保留变量的可配置性，又绕开 attr() 兼容性雷区。如果菜单层级固定 ≤4 级，手写这 4 行比搞 JS 注入 data-level 更轻量、更可靠。
缩进之外：移动端菜单折叠/展开的视觉连贯性怎么保
纯缩进只是样式，用户真正卡住的是“点开后子菜单没对齐”“缩进突然跳变”。这往往因为：transform: scaleY(0) 或 max-height: 0 改变高度时，父容器 padding 没同步重绘，导致子项缩进错位。
- 确保子菜单容器有明确的
overflow: hidden，否则calc()算出的缩进会被溢出内容撑歪 - 缩进用
padding-left，别用margin-left——后者可能被外层 flex/grid 容器截断或忽略 - 动画中缩进值必须和展开状态严格对应：比如子菜单展开时，它的
.menu-item--level-3必须和父项的.menu-item--level-2同时生效，不能靠 JS 延迟加 class
calc() 里的单位混用和负值陷阱
calc(1rem - 2px) 看着合理，但在某些安卓 WebView（尤其旧版 UC 内核）里会直接失效，渲染为 0。移动端必须守住一条线：所有参与 calc 的单位类型要一致。
- 推荐全用
px或全用rem，比如--indent-step: 1rem→calc(var(--indent-step) * 2) - 避免
calc(100% - var(--indent-step))这种写法：百分比在 flex 子项里解析上下文不稳定，容易算成 0 - 不要用负缩进（如
calc(var(--indent-step) * -1)）来“反向对齐”——iOS Safari 对负 calc 结果渲染异常，表现为文字截断或空白
缩进看着是像素小事，但一旦和 touch 区域、focus outline、屏幕缩放叠加，就变成真刀真枪的兼容性战场。变量和 calc 是工具，不是银弹；能用 class 显式声明层级，就别赌 attr() 的未来支持。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
