fixed元素脱离文档流致内容顶入遮挡，须给body或主容器设padding-top等于其渲染后实际高度，而非仅依赖z-index。
直接用 position: fixed 最稳，但必须同步处理遮挡、宽度偏差和移动端软键盘问题；position: sticky 看似聪明，实际在父容器有 overflow: hidden 或 transform 时会静默失效，别指望它“自动工作”。
为什么 position: fixed 加了却内容被盖住？
不是 CSS 写错了，而是 fixed 让导航完全脱离文档流，下面的内容立刻“顶上来”，原地没留空：
- 必须给
或主内容区加padding-top，值严格等于导航栏**渲染后的实际高度**（注意：不是 CSS 里写的height，要考虑字体缩放、行高、内边距） - 别给导航本身设
margin-top——它对布局无影响，只可能造成视觉偏移 - 移动端务必用
width: 100vw而非100%，否则 viewport 缩放或横向滚动时会漏边或溢出 - 如果页面用了
transform（比如轮播图）、filter或perspective，父容器会创建新层叠上下文，z-index可能失效——此时显式写z-index: 1000并确认父级没设overflow: hidden
position: sticky 为什么写了 top: 0 却不粘？
它不是固定，是“临界吸附”，触发条件苛刻，且失败时不报错：
- 父容器设了
overflow: hidden、overflow: auto或任意transform（哪怕只是transform: translateZ(0)），sticky直接退化为relative - 父容器高度不够，或者子元素没撑开它（
height: auto且内容太少），滚动根本触达不到top: 0的临界点 - 必须写双前缀：
position: -webkit-sticky和position: sticky缺一不可，Safari 15.4 之前不认后者 - 导航元素自身要是块级或弹性子项，
display: table或inline会直接失效
滚动监听 + JS 切换 fixed 的真实成本在哪？
适合 banner 播放完再固定、或兼容老浏览器的场景，但容易写出卡顿甚至错位的代码：
- 别在
scroll回调里直接读offsetTop或写style.position——强制同步布局计算，iOS 上掉帧明显 - 用
element.getBoundingClientRect().top 替代window.scrollY > threshold，更可靠（避免因 header 高度变化导致阈值漂移） - 必须节流：用
requestAnimationFrame包一层，或至少用setTimeout+ 标志位防高频触发 - 切换时别只改
position，要同步控制top和left，否则在flex/grid容器中可能水平偏移（尤其有justify-content: center时）
移动端输入框弹起时导航栏乱跳怎么压住？
Android 下 fixed 导航常随软键盘上浮，iOS 可能卡半空——这不是 bug，是浏览器对 viewport 缩放和滚动锚点的处理差异：
- 别依赖
resize或focus事件去动态切fixed/relative，时机难控且触发多次 - 更稳的做法：给
加scroll-behavior: smooth，并在输入框focus时用scrollIntoView({ block: 'nearest' })主动微调视口 - 若必须隐藏导航，用
visibility: hidden而非display: none，避免重排导致页面抖动 - 测试时务必真机连 Chrome DevTools 远程调试，模拟器无法复现软键盘真实行为
真正难的不是写那几行 CSS，而是所有这些边界条件得同时满足——尤其是 fixed 元素在不同缩放、不同容器上下文、不同输入状态下的表现一致性，稍漏一个，用户第一眼就看到错位或遮挡。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
