padding-right 在 overflow-x: auto 容器中“失效”是因滚动条占据右侧空间却不参与 scrollWidth 计算；最可靠解法是外层 wrapper 承担 padding，内层 content 负责滚动。
直接结论：padding-right 在 overflow-x: auto 容器里“失效”，不是 CSS 写错了，而是滚动条吃掉了留白空间；最可靠解法是用外层 wrapper 承担 padding，内层 content 负责滚动。
为什么 padding-right 在水平滚动容器里看不见
典型现象：div { width: 300px; padding-right: 20px; overflow-x: auto; }，内部子元素明明有右内边距，但滚动到底时仍紧贴右边缘。原因在于：
- 滚动条（桌面端约 12–17px）占据容器右侧空间，但它不参与
scrollWidth计算 -
padding-right渲染了背景、影响定位，但不会让可滚动区域变宽 - 移动端 Safari 和 Chrome 的滚动条宽度不一致，硬写固定值（如
padding-right: 15px）必然错位 - 该问题与
box-sizing无关——无论content-box还是border-box，都改变不了滚动锚点停不到 padding 区域的事实
推荐方案：双层结构 —— scroll-wrapper + scroll-content
绕过滚动条干扰，让视觉留白和滚动行为解耦：
- 外层
scroll-wrapper不设overflow，只负责视觉留白：padding-right: 20px完全生效 - 内层
scroll-content设overflow-x: auto，内容宽度由子项撑开，scrollWidth精确反映内容真实尺寸 - 无需猜测滚动条宽度，兼容 iOS Safari、旧版 Android WebView、Electron 等所有环境
<div class="scroll-wrapper" style="width: 300px; padding-right: 20px;">
<div class="scroll-content" style="overflow-x: auto; white-space: nowrap;">
item1 item2 item3
</div>
</div>慎用方案：单层结构下用 calc() 补偿滚动条
仅适用于能接受风险的封闭环境（如内部管理后台、Electron 应用），且必须满足：
立即学习“前端免费学习笔记（深入）”；
- 已知滚动条宽度（例如通过 JS 测量或约定为
16px） - 不需支持 iOS Safari 的动态滚动条（它在滑动时才出现，宽度不可靠）
- 愿意承担缩放或系统设置变更导致补偿失效的风险
示例写法（非通用）：
.scrollable {
width: 300px;
padding-right: 20px;
overflow-x: auto;
}
.scrollable::after {
content: "";
display: inline-block;
width: calc(20px + 16px); /* padding-right + 滚动条宽 */
}容易被忽略的盒模型连锁影响
即使用了 wrapper 方案，若页面其他地方没统一 box-sizing 或残留默认 body margin，仍可能引发横向溢出：
- 务必全局加：
* { box-sizing: border-box; }，否则子元素 padding/border 会意外撑宽容器 -
body必须重置：margin: 0; padding: 0;，否则默认8pxmargin 在缩放后会制造白边 - 图片等替换元素要加：
max-width: 100%; height: auto;，否则原始尺寸会突破父容器宽度
真正卡住人的，从来不是某一行 CSS，而是 body margin + img 未约束 + box-sizing 缺失 + padding-right 放错层——这四个细节叠加，才让留白彻底消失。修复时得一起动，漏一个，滚动到底还是贴边。
