fixed 相对于视口定位，滚动时位置不变；absolute 相对于最近 position: relative 祖先定位，滚动时随父容器移动。
fixed 和 absolute 在隐藏菜单栏里的根本区别
用 fixed 还是 absolute，不是看“动不动”，而是看“参考谁”。fixed 脱离文档流，相对于视口定位，滚动时菜单栏位置不变；absolute 相对于最近的 position: relative 祖先定位，滚动时会跟着父容器走——大多数隐藏菜单（比如侧滑导航、下拉菜单）需要的是前者。
常见错误现象：absolute 做全屏遮罩菜单，一滚动页面，菜单就“飘走”了；或者用 fixed 但没设 top/left，结果菜单卡在左上角动不了。
- 侧边栏菜单（如 hamburger 菜单展开）→ 必须用
fixed，否则无法覆盖内容且不随滚动固定 - 下拉子菜单（如导航栏二级菜单）→ 用
absolute更自然，依赖父级position: relative - 如果父容器有
transform、perspective或filter，哪怕只是transform: translateZ(0)，也会让fixed元素变成相对于该容器定位（Chrome/Firefox 行为），这是最常被忽略的兼容性坑
隐藏 + 动画的关键：transition 不能只靠 display
display: none 和 display: block 之间无法触发 CSS 过渡动画——它是个“开关”，不是“渐变”。想让菜单滑入/淡出，得靠可动画属性：比如 opacity、transform、max-height（需设初始值）。
典型错误：transition: all 0.3s 配合 display 切换，结果动画完全不生效。
立即学习“前端免费学习笔记（深入）”；
- 推荐组合：
opacity+transform: translateX(-100%)（侧滑）或translateY(-100%)（上滑） - 避免用
height动画，因为高度不确定时得写死像素值；max-height更安全，但初始值要设成远大于内容的高度（如max-height: 500px），且收起时设为0 - 动画结束后记得清理内联样式或 class，否则可能影响后续 JS 判断（比如
getComputedStyle(el).opacity返回字符串"0"，但 JS 里仍需手动移除show类）
移动端 fixed 定位的三个现实问题
iOS Safari 和部分安卓 WebView 对 fixed 支持不稳定，尤其在键盘弹出、页面缩放、滚动惯性结束瞬间，菜单栏可能错位、抖动甚至消失。这不是 bug，是渲染优化策略导致的。
常见错误现象：点击输入框唤起键盘后，fixed 菜单被顶到页面顶部之外；或者快速滚动后菜单“卡住”在错误位置。
- 临时方案：检测
focus事件，在输入框聚焦时强制给菜单加position: absolute，失焦再切回fixed - 更稳妥的做法：放弃纯 CSS 方案，用
transform: translate3d(0,0,0)强制硬件加速，同时监听scroll和resize，用 JS 微调top/left（仅限必要场景） - 别依赖
vh单位做高度计算——iOS Safari 的100vh在地址栏隐藏/显示时会变化，导致菜单高度突变
JS 控制显隐时 class 切换的顺序很关键
动画触发依赖 class 变更，但浏览器渲染是异步的。直接 el.classList.add("show") 后立刻操作 DOM（比如读取 offsetHeight），很可能拿到旧值，导致动画卡在起点。
典型错误：用 offsetHeight 判断是否已展开，却在 class 添加后立即读取，结果永远是 0。
- 正确做法：用
getComputedStyle(el).opacity或el.classList.contains("show")做状态判断，而不是尺寸 - 需要精确控制动画节奏时，用
requestAnimationFrame包一层：el.classList.add("show");<br>requestAnimationFrame(() => {<br> el.classList.add("animate");<br>}); - 如果菜单有 backdrop（遮罩层），确保 backdrop 的
z-index比菜单低，且两者都用fixed，否则在某些 Android 浏览器里 backdrop 会盖不住原生 select 或 input
