body{margin:0}未生效主因是根滚动容器为html而非body，需同步设html{overflow-x:hidden}和body{margin:0;padding:0}，并检查绝对定位、图片等隐性溢出源。
body { margin: 0 } 没生效？先查 html 的 overflow 和 computed 样式
直接加 body { margin: 0 } 却还有滚动条，大概率不是你漏写了，而是浏览器把溢出判定交给了 html 元素。iOS Safari 和部分 WebView 中，根滚动容器是 html，不是 body —— 给 body 加 overflow-x: hidden 完全无效，html 才是关键。
必须同步设置：
-
html { overflow-x: hidden; }（不是body） -
body { margin: 0; padding: 0; }（缺一不可） - 这两条规则要放在所有 CSS 最顶部，避免被 reset 或框架样式覆盖
在 DevTools 的 Elements 面板里，选中 html 和 body，分别看 Computed 标签页里的 margin、padding、overflow-x 值——哪怕你写了 margin: 0，也可能被某个 * { margin: 1em; } 覆盖。
left/right 同时为 0 的绝对定位元素正在偷偷加宽
这个最隐蔽：你写了 position: absolute; left: 0; right: 0;，本意是铺满父容器，但浏览器规范要求它忽略 width，改用「父宽 − left − right」反推宽度。一旦父容器有 padding、或 Safari 把滚动条宽度误算进包含块，结果就变成 父宽 + padding-left + padding-right，多出的像素直接触发 scrollWidth > innerWidth。
验证方式：
- 控制台执行
document.body.scrollWidth - window.innerWidth，结果 > 1 就基本锁定是这类定位元素 - 临时删掉所有带
right:或left:的内联样式或 class，滚动条消失 → 就是它 - 修复优先用
transform: translateX(...)替代负值right，或只设单边（left: 0; width: 100vw;）
图片、pre、第三方组件这些“安静的溢出源”根本没报错
它们不抛异常、不警告，但只要没约束尺寸，就是水平滚动条的稳定供应者。比如一个未设 max-width: 100% 的 <img>，或某 UI 库弹窗内部写了 min-width: 320px，在窄屏下直接顶穿容器。
快速定位方法：
- 控制台执行
$$('*').forEach(el => el.style.outline = '1px solid red')，缩放到出问题的尺寸，看哪个红色轮廓“凸出来” - 特别盯紧：
<img>、<pre class="brush:php;toolbar:false;"></pre>、<table>、<code><iframe></iframe>及所有第三方组件的根节点 - 对 Flex/Grid 容器，子项别用
margin-right推宽，改用gap；若需兼容旧 Safari，margin必须配overflow-x: clip - 用
width: 100%（基于父容器宽度，不含滚动条） - 用
width: 100dvw（动态视口单位，排除滚动条） - 硬算用
calc(100vw - 40px)，但要确保减的值准确（可用 JS 动态计算document.documentElement.clientWidth - document.body.offsetWidth） - 别在
body或全屏容器上混用100vw和padding，这是高发区
100vw 在 Windows 和缩放场景下天然比视口宽
100vw 包含垂直滚动条宽度（约 15–17px），在 Windows 下尤其明显。你写 width: 100vw + padding: 0 20px，实际宽度就是 100vw + 40px，铁定溢出。
安全替代方案：
真正难搞的从来不是某一行代码写错了，而是多个看似无害的默认行为叠加：body 的 margin、html 的 overflow 默认 visible、100vw 的滚动条误差、再加上一个没设 max-width 的图片 —— 它们各自只贡献 1–2px，合起来就稳稳触发滚动条。排查时得像拆电路一样，逐级断电测试，而不是指望一个 overflow-x: hidden 一劳永逸。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
