不能直接写 translateX(-280px) 因其为硬编码，宽度变化时错位；translateX(-100%) 在 flex 或 overflow:hidden 下按父宽计算致关不严；需配合 width 和 position 使用 --drawer-width 变量。

为什么不能直接写 translateX(-280px)？

因为 280px 是硬编码，一旦抽屉宽度随设备或主题变化（比如暗色模式下加了 padding），位移就错位。更糟的是，translateX(-100%) 在 flex 容器或某些父级 overflow: hidden 下会按父宽算，不是抽屉自身宽——结果关不严、露边、点击穿透。

--drawer-width 必须配合 width 和 position 才生效

CSS 变量本身不触发重排，但它的值要真正影响位移，得满足三个前提：

• .sidebar 必须设 width: var(--drawer-width);，不能靠内容撑开
• 必须是 position: fixed 或 position: absolute，否则 translateX(calc(-1 * var(--drawer-width))) 会被文档流干扰
• 变量定义位置要合理：推荐写在 :root 或组件 scope 的 class 上，避免被继承污染

移动端用 calc() 算位移时的兼容性雷区

旧版 Android WebView（尤其微信 7.0.20 以下）对 calc(var(--x) * -1) 支持极差，容易解析成 0。稳妥写法是：

CSS工具箱(专业版)

全功能 CSS 工程手册，覆盖性能优化、无障碍、设计系统与跨浏览器兼容。

下载

• 用 translateX(calc(-1 * var(--drawer-width))) 而不是 translateX(calc(var(--drawer-width) * -1)) —— 前者在低版本中更可靠
• 如果抽屉含滚动内容，额外加 backface-visibility: hidden，防止 iOS Safari 渲染层错乱导致位移抖动
• 别在 transition 中混用 var() 和 px 单位，比如 transition: transform 0.3s ease, opacity 0.3s 没问题，但 transition: all 0.3s 可能让浏览器误判动画属性

动态改 --drawer-width 后位移没更新？检查这三点

变量值变了，但 transform 没反应，通常不是 CSS 问题，而是渲染链断了：

• 确保变更变量的 JS 是同步执行的，比如 document.documentElement.style.setProperty('--drawer-width', '320px') 后不要立刻读 getComputedStyle，它可能还没 flush
• 如果抽屉用 visibility: hidden 隐藏过，改变量后需先 visibility: visible 再触发动画，否则 transition 不触发
• Android WebView 中，calc() 里嵌套函数（如 min() 或 max()）大概率失效，只保留最简四则运算

真实难处不在“怎么写变量”，而在于：你改了变量，浏览器未必真按你预期的方式重新合成那一帧——尤其当它正忙着处理 touchmove 或 scroll 事件时。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！