答案是：fixed元素因脱离文档流且默认z-index较高，会遮挡overflow-y:scroll容器的右侧滚动条。解决方法包括：用right:15px微调定位避开滚动条、改用flex布局使导航成为流内元素、避免使用已废弃的overflow:overlay。
fixed元素不占文档流，但会遮挡滚动条
position: fixed 元素天然脱离文档流，所以它不会挤压、推挤或影响其他元素的布局位置——这点没错。但问题常出在视觉和交互层：它默认叠在所有内容之上，尤其容易盖住 overflow-y: scroll 容器右侧的原生滚动条。
这不是“影响其他元素”的传统意义（比如 margin/padding 被撑开），而是 fixed 元素凭空悬浮，且 z-index 默认较高，导致滚动条不可见、不可点。用户拖不动、点不准，误以为页面卡死。
- Windows 系统下滚动条常占约
17px宽度，width: 100%的 fixed 元素会严格按视口宽度渲染，直接压住这17px - macOS 或移动端滚动条自动隐藏时，问题不明显；但一旦出现（比如调试时强制显示），遮挡立刻暴露
- 即使没滚动条，
z-index设置不当也可能让 fixed 元素盖住弹窗、下拉菜单等交互组件
用 right 或 inset 避开滚动条区域
最轻量、兼容性最好的解法不是改布局结构，而是微调 fixed 元素自身的定位值，让它主动“让出”滚动条空间。
关键不是删掉 width: 100%，而是用 right 值覆盖它的右边界行为：
立即学习“前端免费学习笔记（深入）”；
.header {
position: fixed;
top: 0;
left: 0;
width: 100%; /* 保留，确保横屏适配 */
right: 15px; /* ← 实际生效：浏览器会按 right + left 计算宽度，自动减去约 15px */
}-
right: 15px不是 magic number，而是对常见滚动条宽度（15px–17px）的经验补偿 - 如果项目用了
postcss-pxtorem，必须写成内联样式:style="{ right: '15px' }"，否则编译后变成rem单位，在不同根字号下可能失效 - 现代写法可用
inset替代四边偏移：inset: 0 15px auto auto，但 IE 完全不支持，需权衡
overflow: overlay 是快捷方案，但支持有限
overflow: overlay 的本意是让滚动条浮在内容上层，理论上能绕过 fixed 元素遮挡问题。但它只在旧版 WebKit（如 Safari 6–9）中有效，Chrome 和 Firefox 已废弃该属性，实际已不可靠。
- 当前 Chrome/Firefox 中设置
overflow: overlay会被忽略，回退为auto - MDN 明确标注该值为“非标准”，不建议用于新项目
- 若看到网上教程推荐它，大概率是未更新的过时方案
真正不影响其他元素，得管住 z-index 和 containing block
fixed 元素虽不占流，但它的渲染上下文和层级极易被干扰。两个隐形坑比遮挡滚动条更难排查：
- 祖先元素若有
transform、filter、opacity < 1，会创建新的 containing block，导致 fixed 元素退化为相对该父容器定位，而非视口 —— 此时它突然“跟着滚”，看似失效 -
z-index只在同级层叠上下文中生效。如果 fixed 元素和某个 modal 同属 body 下，但 modal 的父容器有transform，那它们不在同一 stacking context，z-index就无法跨 context 比较 - 移动端 iOS Safari 中，fixed 元素在软键盘弹出、快速滚动时可能闪烁或错位，这不是 CSS 能单点修复的，需配合
visualViewportAPI 动态调整top
真正让 fixed “不影响其他元素”，重点不在让它消失，而在让它安分：不抢滚动条、不被父级劫持、不乱盖别人、不随软键盘飘走。
