根本原因是html设置非visible的overflow会使其成为fixed元素的包含块，导致fixed脱离视口而锚定在html内；应确保html overflow为visible，滚动交由body处理。
给 html 设置 overflow 会破坏 fixed 的定位基准
根本原因：当 html 元素被显式设置 overflow: auto 或 overflow: hidden 时，它会成为新的“包含块（containing block）”，而 position: fixed 元素的定位参照物就从视口（viewport）退化为这个 html 容器——这直接违反了 CSS 规范中对 fixed 的定义（应相对于初始包含块，即视口）。
浏览器实际行为是：一旦 html 有了非 visible 的 overflow 值，且自身具备可滚动能力（比如内容溢出），fixed 元素就会锚定在 html 的滚动边界内，而不是屏幕边缘。滚动时它可能“跟着动”、偏移、甚至被裁剪。
- 常见诱因包括：
html { overflow-y: scroll; }、html { overflow: hidden; }（尤其在某些重置样式或 UI 框架中静默注入） -
html上的transform、filter或opacity < 1也会触发同样退化，但overflow是最隐蔽也最常被忽略的 - 用开发者工具检查
html的 Computedoverflow值，若不是visible（注意：visible是初始值，不等于未声明），基本就是它
body 滚动 vs html 滚动：谁该负责可滚动上下文？
标准滚动链中，body 才是内容承载主体；html 应保持为“初始包含块”角色。把滚动交给 html，等于让定位锚点和滚动容器耦合，fixed 必然失准。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 正确做法：清空
html的overflow（确保 computed 为visible），把滚动控制权交还给body - 典型安全配置：
html { height: 100%; overflow: visible; }+body { min-height: 100vh; overflow-y: auto; margin: 0; } - 避免
html { height: 100%; overflow: auto; }这类写法——它看起来“撑满全屏”，实则悄悄劫持了fixed的坐标系
移动端 iOS Safari 中这个问题更严重
iOS Safari 对 html 滚动的处理更敏感：软键盘弹出、地址栏收起、页面缩放时，只要 html 有非 visible 的 overflow，fixed 元素就极易跳动或完全失效——因为视口尺寸动态变化，而 html 容器无法及时同步其“新边界”。
立即学习“前端免费学习笔记（深入）”；
- 真机测试时，哪怕桌面端表现正常，也要重点验证键盘唤起后
fixed导航栏是否还在顶部 - 临时规避方案（不推荐长期用）：
html { overflow: visible !important; }+ 在 JS 中监听resize和focusin，动态重设body.style.position = 'relative'等辅助手段 - 终极解法仍是结构归位：所有滚动逻辑只作用于
body或业务容器，html不参与布局计算
为什么你查不到 html 的 overflow 却还是出问题？
很多框架（如 Normalize.css、某些 UI 库）或构建工具会在 html 上注入 overflow-x: hidden 用于防横向滚动，却漏掉了 overflow-y，导致 overflow 计算为 hidden（CSS 层叠规则：overflow-x: hidden + overflow-y: visible → overflow: hidden）。
- 务必检查 Computed 面板中的完整
overflow值，不要只看 Styles 面板里你写的那条 - 用
getComputedStyle(document.documentElement).overflow在控制台直接读取，确认是否为visible - 如果发现是
hidden或auto，加一条html { overflow: visible !important; }就能快速验证是否根因
html。 
