直接禁用Bootstrap的padding-right补偿逻辑最可靠；modal-open导致“向左一缩”是因为Bootstrap 5为抵消滚动条消失而给body内联设置padding-right（如17px），但fixed元素不响应此值，视觉上内容左移。
直接禁用 Bootstrap 的 padding-right 补偿逻辑，比修复它更可靠；抖动不是 bug，是它主动加的补偿在 fixed 元素、自定义滚动或第三方库干扰下失效所致。
为什么 modal-open 会让页面“向左一缩”
Bootstrap 5 在模态框显示时给 body 加 modal-open 类，并内联设置 padding-right（比如 17px），目的是抵消 overflow: hidden 导致的原生滚动条消失。但这个补偿只作用于 body 的流式内容，position: fixed 的导航栏、页脚、全屏背景图等元素不会同步右移——视觉上就像整个页面被吸向左边。
- macOS Safari 滚动条宽度常为
0，补偿反而造成右侧多余空白 - 用了
overlay-scrollbars或perfect-scrollbar？它们接管原生滚动，document.body.offsetWidth - document.documentElement.clientWidth返回0，Bootstrap 就不补，但overflow: hidden仍生效，结果就是内容突然右跳 - 全局 CSS 写了
body { padding-right: 0 !important }？直接覆盖补偿值，抖动更明显
用 data-bs-backdrop="static" 彻底绕过补偿
这是最轻量、副作用最少的解法：它跳过整个 padding-right 注入流程，不加 modal-open 类，也不改 body 的 padding，只禁用点击遮罩关闭，保留 ESC 键关闭能力。
- 只需在 modal 标签加属性：
<div class="modal" data-bs-backdrop="static"> <li>不影响键盘交互，<code>data-bs-keyboard="false"才禁用 ESC - 不污染全局样式，不干扰下拉菜单、Tooltip 等依赖
body宽度的组件 - 多层 modal 场景下也不会因
modal-open提前移除导致背景意外可滚 - 给所有 fixed 元素加上该类：
<nav class="navbar fixed-top is-fixed"></nav>、<div class="hero-bg is-fixed"> <li>不加这个类，就得自己监听 <code>show.bs.modal/hidden.bs.modal手动同步，容易漏掉或重复执行 - 若用了自定义滚动方案（如
scrollbar-gutter: stable），可重写 Modal 的checkScrollbar方法，返回固定宽度（如16），避免依赖 DOM 计算 - 监听
show.bs.modal时：获取真实滚动条宽度，设document.body.style.paddingRight = `${width}px`，再设document.body.style.overflow = 'hidden' - 监听
hidden.bs.modal时：必须执行document.body.style.paddingRight = ''（不是'0'或null），否则后续页面滚动错位 - 绝对不要写
.modal-open { padding-right: 0 !important }——这个类本身不带 padding，真正起作用的是内联 style，且硬编码会破坏不同系统/缩放下的适配
必须保留点击遮罩关闭？那就加 .is-fixed 类
Bootstrap 5 内置了对 position: fixed 元素的补偿支持，但前提是显式加 .is-fixed 类——它本身无样式，只是个钩子，JS 会监听 modal-open 状态，自动为带该类的元素同步增减 padding-right。
立即学习“前端免费学习笔记（深入）”；
手动接管滚动控制时，padding-right 必须清干净
如果绕过 Bootstrap 的 JS 流程（比如手写 show/hide 逻辑），最容易漏掉的是还原步骤：只删 modal-open 类，却没清内联 padding-right，或者设成空字符串 '' 而不是 ''（注意引号类型）。
真正麻烦的从来不是选哪种技术方案，而是检查是否已有第三方库或自定义 CSS 悄悄修改了 body 的 overflow 或 padding —— 这些隐性覆盖往往比抖动本身更难定位。
