fixed定位被滚动条遮挡？从滚动条占位到Pxtorem适配全解析

好几天前，我在调一个后台管理系统的悬浮操作栏，代码明明写的position: fixed; right: 0; top: 80px;，桌面端预览时却总觉得不对劲：操作栏右边缘和窗口右侧贴得死死的，滚动条一出现，右边一排按钮就被“咬”掉一截，看着像是被什么东西挤压过。后来我把right: 0换成right: 15px，问题瞬间消失。折腾完才发现，整条排查链路上最不起眼的环节——滚动条宽度，才是真正的主角。这篇内容就来完整记录 fixed 定位导致滚动条遮挡问题的来龙去脉，以及right: 15px这种看似简单但很实用的处理思路，顺带把接入 Pxtorem 插件后遇到的适配问题一起说清楚。

触发这个问题的场景非常典型：页面内容超过一屏，垂直滚动条出现，页面上恰好又有一个 fixed 定位的弹层、抽屉或悬浮工具条。如果你也是写 PC 管理后台、富交互页面这类东西的前端，大概率早晚会撞上它。

1. fixed 元素右侧被“咬掉”的真实案发现场

1.1 一个常见却容易被归为“灵异问题”的现象

先说现场。某后台项目的订单详情页，右侧需要悬浮一个快捷操作面板，方便审核人员快速通过或驳回。我当时的代码没有任何花哨操作：

.order-float-panel { position: fixed; top: 80px; right: 0; width: 320px; background: #fff; box-shadow: 0 8px 24px rgba(0, 0, 0, 0.12); }

页面内容不算特别长，正常打开时看着没问题。但只要把浏览器窗口缩小一点点，或者内容区域达到一定高度触发了垂直滚动条，这个面板的右侧边缘就会和滚动条“挤”在一起。更明显的是，如果给面板加了边框或阴影，右边缘的阴影会被滚动条区域遮住，视觉上像被切了一刀。共事过的几个同学第一反应都是“该不会父级有 transform 导致 fixed 失效了吧”“是不是定位上下文出问题了”，查了一圈发现全是常规用法。

这类问题之所以容易被当成灵异事件，是因为position: fixed太常见了，大家默认它一定贴着“整个屏幕”的右边。实际上，在经典滚动条模式下，它贴住的是“去掉滚动条之后的可视区域”的右边。滚动条本身占着地方，你的元素看着就像被咬掉一块。

1.2 滚动条如何改变 fixed 的参照系

要理解right: 0到底定位到哪，得把 fixed 的参照系说清楚。规范里 fixed 定位的元素是相对于视口定位的，但“视口宽度”在不同场景下的表现并不是一个恒定值。部分桌面系统的经典滚动条是会占用视口右侧空间的，这块宽度不算进可用渲染区域。于是 fixed 元素的right: 0在实际渲染时，等于紧贴可用区域右边界，也就是滚动条左边缘。

拿最常见的情况举例：页面出现垂直滚动条后，滚动条宽度按常见的 15px 算，那么你的 fixed 元素右边缘距离“浏览器窗口物理右边缘”大约就是 15px。这 15px 空间被滚动条占了，元素表面上看就是被滚动条压着。

还有另一种更严重的表现：很多人写全屏遮罩会顺手加width: 100vw。

.modal-mask { position: fixed; left: 0; top: 0; width: 100vw; height: 100vh; background: rgba(0, 0, 0, 0.5); }

在经典滚动条模式下，100vw会把滚动条占用的宽度也包含进去，于是遮罩层右侧会多出一截滚动条宽度的背景，直接盖到滚动条下方。如果你在遮罩上放了关闭按钮，按钮位置也会整体右偏。这类现象本质上都是同一个原因：把“视口”理解成了“屏幕”，但 fixed 元素实际能用的可视区域，要比物理屏幕宽度更窄。

1.3 15px 这个数值到底从哪来

很多方案文章会直接告诉你“设成 right: 15px”，但没说这个 15px 是怎么来的。传统桌面系统的经典滚动条，宽度通常在 14px 到 17px 之间波动，15px 是一个偏保守的中位经验值。也就是说，设right: 15px相当于人为给滚动条预留了一个安全间隙，让 fixed 元素在出现滚动条时不会被挤到，不出现滚动条时也只是右侧多了一点留白，视觉上完全可接受。

注意：这个 15px 不能理解成“所有平台都一样”。部分笔记本系统默认使用浮层滚动条，平时不占空间，只有滚动时才会浮出来盖在内容上方。这种情况下滚动条宽度为 0，right: 15px反而会多出 15px 空隙。解决办法不是机械地固定一个数值，而是理解清楚滚动条模式，再决定用固定值还是用 CSS 变量动态处理。

2. 为什么说 right: 0 不是写错，而是参照系差异

2.1 占位模式与浮层模式的行为差异

把滚动条模式分成两类，很多困惑会立刻消散。占位模式是传统桌面系统的常见行为：滚动条长期占据视口右侧一个固定宽度，页面内容可用宽度减小。浮层模式则常见于部分笔记本系统，滚动条平时隐藏，触摸板或鼠标滚动时临时浮在内容上，不占用布局宽度，页面内容可用宽度始终等于视口宽度。

在占位模式下，right: 0本身不是“错”的，它确实按照定位规则工作，只是定位的参考边不是浏览器窗口物理右边界，而是“排除滚动条后的可视区域右边界”。理解成“视口可用空间”会更准确。可如果页面上同时存在width: 100vw之类的写法，问题就会从“贴得太紧”升级成“直接盖到滚动条下面”。

2.2 vw 不等于可视宽度：一个常见误判

vw单位定义是“视口宽度的 1%”，但实际浏览器在计算时，不同内核处理滚动条宽度的策略并不统一。经典滚动条模式下，常见表现是100vw会包含滚动条宽度，也就是“物理视口宽度”，比实际可用宽度多出大约 15px。这时如果你用width: 100vw做一个 fixed 背景层或遮罩层，右侧就会出现一条被滚动条遮挡的“残影”。

我见过一个比较典型的错误用法，是拿100vw去做左侧固定导航栏的宽度基准：

.sidebar { position: fixed; left: 0; top: 0; width: 100vw; }

本来想的是“导航栏铺满整个屏幕宽度”，结果内容区直接被挤出一截，页面还出现了横向滚动条。更合适的写法通常是用left: 0; right: 0;同时拉满，或者只给width: 100%。但要注意，width: 100%对 fixed 元素来说，百分比参照的是包含块宽度，在很多场景下就等于可用视口宽度，和100vw的结果不同。这也是很多前端容易踩的细节。

2.3 常见“修复”为什么越改越糟

遇到右侧被遮挡，新手最容易想到的修法是加负 margin 或负的 right 值。比如把right: 0改成right: -15px，以为把元素往右推就能避开滚动条。实际效果恰恰相反，在占位模式下这会让元素往滚动条下面钻得更深，被遮挡的部分更多。还有人会尝试给 fixed 元素的父级加padding-right: 15px或者margin-right: 15px，但 fixed 元素根本不受父级 padding 影响，它只认视口，这种改法完全无效。

另一个迷之操作是给body或html设置overflow-x: hidden，想靠隐藏横向滚动条来压制问题。如果页面本身没有横向溢出，这确实能掩盖一部分视觉瑕疵，但一旦某个弹层实际宽度超过视口，右侧内容还是会被裁掉，而且排查问题的难度反而更高。我的建议是，这类问题尽量别用“掩盖式”修法，先把参照系和滚动条模式确认清楚，再决定间距怎么写。

3. 从 right: 15px 到完整适配方案

3.1 基础写法：把 15px 写进 calc 更安心

直接写right: 15px是最简单的处理方式，绝大多数经典滚动条场景都能解决。不过如果想兼容移动端安全区，更好的写法是把它放进 calc 里：

.fixed-panel { position: fixed; top: 80px; right: calc(15px + env(safe-area-inset-right)); width: 320px; }

env(safe-area-inset-right)是移动端浏览器提供的信息，表示设备右侧安全区域距离。iPhone 这类带圆角或刘海屏的设备在横屏时，如果 fixed 元素贴着屏幕右边，按钮可能被物理结构挡住，加上这个变量后就能自动偏移。桌面端没有安全区，等式里的env(safe-area-inset-right)会视为 0，所以这个写法不会破坏桌面端的表现，可以直接统一使用。

3.2 现代 CSS 的另一种视角：scrollbar-gutter: stable

有时候页面在滚动条出现和消失之间来回切换，内容布局会左右跳动，这种抖动体验很糟。CSS 新属性scrollbar-gutter: stable可以提前为滚动条预留出槽位，让页面始终保留滚动条的占位宽度，从而避免内容跳变。

html { scrollbar-gutter: stable; }

需要注意，scrollbar-gutter影响的是文档流里的内容布局区域，但它并不会自动帮 fixed 元素让出位置，因为 fixed 定位元素的参考系是视口，不是 scroll container 的内容盒。所以这个属性和right: 15px不冲突，反而是互补的：scrollbar-gutter负责保证普通的文档流内容不抖动，right: 15px负责保证 fixed 元素避开滚动条。两个一起用，效果是稳定且干净的。

3.3 动态测量滚动条宽度的 JS 方案

如果项目里对滚动条宽度有高精度要求，比如设计稿严格规定固定元素和屏幕右侧距离是 12px，那么可以动态测量滚动条实际宽度，把它写进 CSS 变量：

function getScrollbarWidth() { const div = document.createElement('div'); div.style.cssText = 'position:absolute;top:-9999px;width:100px;height:100px;overflow:scroll;'; document.body.appendChild(div); const width = div.offsetWidth - div.clientWidth; document.body.removeChild(div); return width; } document.documentElement.style.setProperty('--sbw', getScrollbarWidth() + 'px');

CSS 里就能这样用：

.fixed-panel { right: calc(12px + var(--sbw, 15px)); }

这个方案的优势是精确，能适应不同系统的滚动条宽度。缺点是要在页面初始化时跑一段 JS，而且滚动条宽度如果因为系统设置变化而改变，需要重新计算。大多数项目其实用不到这么重的手段，right: 15px配合calc已经足够。

3.4 几种方案的选型对比

我自己的项目选型逻辑很简单：通用业务页面直接用right: 15px，需要兼顾移动端的组件把安全区变量加进去；如果排查到页面因为滚动条出现而内容变宽变窄，再补scrollbar-gutter: stable。JS 测量方案只在做跨端组件库时用过，业务里用确实有点杀鸡用牛刀。

4. Pxtorem 插件介入后的连锁反应

4.1 插件默认会连 right 一起转换

现在很多移动端项目会使用 Pxtorem 插件（对应 postcss-pxtorem）做单位转换，把 CSS 里的 px 自动折算成 rem，方便按设计稿进行等比适配。如果你在配置里用了最常见的写法：

module.exports = { plugins: { 'postcss-pxtorem': { rootValue: 37.5, propList: ['*'] } } };

那么right: 15px会按照15 / 37.5被换算成right: 0.4rem。如果设计稿宽度是 375，rootValue取 37.5，这个换算在移动端没有毛病，0.4rem 算出来刚好是 15px。可问题在于，这个规则是无差别转换的，它不会因为你写的是 fixed 层就特殊照顾。

于是桌面端场景就复杂了：桌面浏览器根本不会把html的font-size设置成 37.5px，而是浏览器默认的 16px。那么0.4rem的实际像素值就是0.4 * 16 = 6.4px，和你想要的 15px 差了十万八千里。fixed 元素右侧的间距瞬间缩水，甚至可能回到和滚动条贴死的状态。这也是很多人刚接入 Pxtorem 后突然发现“怎么原来好的地方又坏了”的原因。

4.2 一个让 rem 方案走样的隐藏配置

Pxtorem 插件有几个配置项，默认值很容易让人忽略，但它们直接决定转换结果。

minPixelValue默认是 0，意思是所有大于 0 的 px 都会被转换。如果你有一条border-right: 1px solid #eee，1px 也会被转成 0.02666667rem，在部分浏览器里可能出现边框变粗或消失的问题。所以很多团队会把minPixelValue设为 2，小数值保留 px，15px 照样会转换。

mediaQuery默认是 false，也就是媒体查询内部的 px 不会转换。这个默认值在某些情况下反而是保护伞，比如你想在桌面断点里保留固定 px 间距，可以故意把相关规则写在媒体查询里，让它不被转换。

还有selectorBlackList，默认是空数组。这个配置决定哪些选择器整体不做转换，非常好用，但很多人不知道它的匹配规则：数组里的字符串当成正则还是字符串匹配，取决于实现方式，项目中最好先做小范围验证再推进。我曾经把.desktop写进黑名单，结果所有包含.desktop的类名规则都被跳过转换，看起来没问题，但换个命名方式后规则又失效了。

4.3 控制转换范围的三种方法

第一种是配置propList，只让插件转换你期望转换的属性。但实际项目中这样做成本不低，因为 width、height、font-size、padding、margin 这些几乎都需要 rem 适配，把 right 单独从列表里摘出来反而显得另类。

第二种是使用selectorBlackList，给桌面端 fixed 组件一个独立类名，直接整块不转。例如：

selectorBlackList: ['.keep-px', '.fixed-layer']

.fixed-layer { right: 15px; }

这样插件在遇到.fixed-layer时会跳过整条规则，15px 得以保留。这是目前团队里用得最多的方式，因为它能控制到组件级，语义也清楚。

第三种是行内注释法，在具体声明的值后面加/* px */，告诉插件这条不要转：

.fixed-panel { right: 15px; /* px */ }

这种方式粒度最小，适合不需要大规模隔离、只有少数几条规则要保留 px 的场景。但缺点是注释散落在 CSS 里，样式多了以后不好维护。我给的建议是：如果只有一两处固定定位层，用注释法最省事；如果项目里桌面端组件不少，组一个黑名单类名统一处理更合适。

5. 完整配置参考与构建产物验证

5.1 postcss.config.js 参考配置

下面这份配置是我在实际项目里打磨过一遍的参考版本，兼顾移动端 rem 适配和桌面端 fixed 层保留 px 的需求：

module.exports = { plugins: { 'postcss-pxtorem': { rootValue: 37.5, // 以 375 设计稿为基准 unitPrecision: 5, // rem 小数点位数 propList: ['*'], // 默认转换所有属性 selectorBlackList: ['.keep-px', '.fixed-layer'], minPixelValue: 2, // 2px 及以下不转换 mediaQuery: false // 媒体查询里的 px 不转 } } };

rootValue 的选择和设计稿宽度强相关。团队用 375 宽度设计稿，rootValue 可以用 37.5；如果设计稿是 750，rootValue 建议改成 75。换算后 15px 会变成 0.2rem，依然是 15px 的显示效果。关键是团队内部必须统一这个基准值，不然后端联调时会出现整套字体和间距集体偏大或偏小的问题。

5.2 CSS 源码与构建产物对照

验证配置有没有生效，最直接的办法是看构建后的 CSS。源代码长这样：

.fixed-layer { right: 15px; } .mobile-panel { right: 15px; }

构建完成后，因为.fixed-layer命中黑名单，它的右间距保留 px；.mobile-panel是普通规则，15px 被折算成 rem：

.fixed-layer { right: 15px; } .mobile-panel { right: 0.4rem; }

我在项目排期时习惯于把“构建产物变更”纳入代码审查范围。改完 CSS 不是看一眼效果正常就行，还要在 dist 目录里搜一下fixed-layer，确认这个类名下没有出现 rem 数值。这一步成本很低，但能拦截掉大量“本地一切正常，上线后偏移几像素”的隐患。

5.3 二次踩坑：选择器黑名单与设计稿缩放

第一个坑是黑名单的匹配规则。selectorBlackList: ['.fixed-layer']会命中所有包含这个字符串的选择器，但如果你在一条规则里同时写了.fixed-layer和其他类名，比如.fixed-layer.active，插件也会跳过转换。这通常没什么问题，可一旦你写的是.active而不是.fixed-layer，这条规则照样会被转换，视觉上就会出现同一个组件里两种单位混用的情况。

第二个坑和设计稿缩放有关。项目中途设计稿从 375 宽切图变成 750 宽切图，如果只把 rootValue 从 37.5 改成 75，那么所有原本写在设计稿里的 px 数值在换算后视觉大小不变。但如果你同时又把设计稿里直接标出的 300px 当成原始值来用，换算结果就会翻倍。这件事虽然不是 Pxtorem 的 bug，但最容易在混合场景里爆发，因为 fixed 层的 right 值总是很小，翻倍后看着特别明显。我的处理经验是：设计稿改版时，除了配置项，把 CSS 里的关键注释也同步更新，避免后续维护者被两种换算逻辑绕晕。

6. 排查链路复盘：以后再遇到定位偏移怎么入手

6.1 从现象倒推：先确认到底是哪一层在偏移

如果以后再碰到 fixed 元素偏了、被遮了、莫名多出间距之类的问题，别再一上来怀疑定位语法，按下面这张表逐层排除：

优先级上，先确认有没有width: 100vw，再看滚动条模式，再查构建产物，最后才查定位上下文。因为定位上下文导致的 fixed 元素失效会有更明显的表现，比如元素直接变成相对某个父级移动，而不是单纯差十几像素。

6.2 临时标注法：用 1px 边框和背景色逼出真相

排查偏移问题时，我有个很好用的小套路：给目标元素加上临时样式，让它“现形”。

.fixed-panel { outline: 2px dashed red; background: rgba(0, 0, 255, 0.2) !important; }

然后逐步修改right的值，在 0、15px、calc 表达式之间来回切换，同时观察滚动条和元素边缘的位置关系。如果outline的边界始终和滚动条左边缘贴在一起，那说明问题就是滚动条占位；如果蓝色半透明背景盖到了滚动条下方，说明 width 或 100vw 的计算跑偏了。这个方法不需要任何调试工具，肉眼就能判断是哪一层出了问题。

再补充一个辅助手段：在元素右侧放一个和滚动条等宽的参照块，宽度固定为 15px，同样 fixed 定位。对照它和真正滚动条的关系，就能立刻知道自己预留的间距到底够不够。调试完记得把所有临时样式删干净，避免把!important留在生产代码里。

6.3 回归测试要点

修复完成不能只看一种状态，至少要在这些场景下过一遍：

• 页面内容不足一屏时，fixed 元素表现是否正常。
• 页面内容超过一屏、出现垂直滚动条时，fixed 元素是否还会被挤压。
• 切换到“始终显示滚动条”和“自动隐藏滚动条”两种系统模式，观察间距是否符合预期。
• 路由切换前后，fixed 元素是否保持在同一个位置，没有被路由过渡动画影响。
• 如果项目接入了 Pxtorem，打开构建产物确认目标选择器下的 right 值到底是 px 还是 rem。
• 移动端横屏下，检查env(safe-area-inset-right)是否生效，按钮是否被物理边缘挡住。

最后再分享一个小技巧，我会在项目的全局 CSS 中定义一个语义化变量，比如--scrollbar-gap: 15px;，然后 fixed 层的 right 都引用这个变量。这样以后滚动条宽度或产品视觉规范有调整，只改一行就能全局生效。如果你最近也在被 fixed 定位和 rem 转换来回折腾，可以按这篇的顺序走一遍，大部分问题都能在构建产物和 DevTools 的 computed 面板里找到答案。