element ui 菜单缩进应避免硬编码 padding-left，改用 css 变量 --menu-indent 配合层级 class 精确控制，支持 rtl 的 margin-inline-start 更可靠，attr() 动态计算不实用。
为什么直接写 padding-left: 48px 会失控
Element UI 的 .el-menu--inline .el-menu-item 默认是 padding-left: 48px，但这个值不是“二级缩进 = 20px × 2”，而是硬编码的近似值（含图标预留空间），三级又变成 68px 或 88px，靠猜数字 patch 一改就崩。更麻烦的是，它被多层嵌套选择器叠加（如 .el-menu .el-menu--inline .el-menu-item），你写的 .el-menu-item { padding-left: 32px } 很可能被忽略。
用 --menu-indent 变量 + 嵌套类名控制缩进层级
别依赖 DOM 深度（比如 .el-menu--inline .el-menu--inline 套几层），Element UI 渲染时子菜单容器虽带 .el-menu--inline，但内部项不自动继承“当前层级”语义。稳妥做法是给最外层 <el-menu></el-menu> 加一个 class（如 menu-root），再逐级显式匹配：
-
:root { --menu-indent: 16px; }—— 全局可被主题系统覆盖 .menu-root .el-menu-item, .menu-root .el-submenu__title { padding-left: calc(var(--menu-indent) * 0); }.menu-root .el-menu--inline .el-menu-item, .menu-root .el-menu--inline .el-submenu__title { padding-left: calc(var(--menu-indent) * 1); }.menu-root .el-menu--inline .el-menu--inline .el-menu-item, .menu-root .el-menu--inline .el-menu--inline .el-submenu__title { padding-left: calc(var(--menu-indent) * 2); }
这样每级缩进严格等于 16px × (层级 - 1)，且不会因父容器样式污染而失效。
margin-inline-start 比 padding-left 更适合 RTL 场景
如果菜单要支持阿拉伯语或希伯来语等右向文本，padding-left 会让子菜单顶到右边，结构全乱。而 margin-inline-start 自动适配书写方向：LTR 下等效 margin-left，RTL 下等效 margin-right。
- 兼容性够用：Chrome 69+、Firefox 63+、Safari 12.1+ 都支持
- 别和
text-align: end混用——容易导致文字与缩进方向打架 - 若必须兼容 IE，则退回
padding-left+direction: rtl手动翻转，但得额外加 class 控制
避免用 attr(data-level) 在 calc() 中动态计算
虽然看着很理想：padding-left: calc(var(--indent-step) * (attr(data-level number, 1) - 1))，但实际中 attr() 在 calc() 里几乎不工作：Chrome 115+ 才开始实验性支持，Safari 完全不认，Firefox 支持有限。强行用会导致各级缩进全部回退为 0。
- 真正可用的方案是把层级“编译”进 class 名，比如
.menu-item--level-2，再配合变量驱动 - 如果菜单层级固定 ≤4 级，手写 4 行 CSS 比 JS 注入
data-level更轻量、更可靠 - 伪元素缩进（如
::before { content: " "; font-family: monospace; }）仅适用于无法修改 DOM 的 CMS 场景，非首选
复杂点在于：缩进逻辑必须和定位逻辑解耦。哪怕你用 calc() 算对了 padding-left，如果父级没设 position: relative，子菜单仍会飘到页面左上角——这和缩进变量无关，但常被一起排查。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
