width: 100%在移动端“失效”主因是其计算基准为父元素content box，受padding/border、viewport缺失、box-sizing未重置、父容器宽度链路断裂及100vw混用等隐性因素叠加影响，导致总宽超出视口。
不是width: 100%本身有问题，而是它在移动端常和几个隐性因素叠加，导致总宽超出视口——最常见的是padding、margin、100vw单位混用，以及父容器宽度链路断裂。
为什么width: 100%在移动端会“失效”
移动端屏幕窄，但width: 100%的计算基准仍是父元素的内容区宽度。如果父元素有padding: 0 20px，那它的内容区就比总宽小 40px；子元素设width: 100%，实际只占这 280px（假设父总宽 320px），再加自己padding: 10px，总宽就变成 300px → 看似没溢出，但若父容器本身又嵌套在display: flex里且没设flex-shrink: 0，它可能被压缩后又撑开，最终触发横向滚动条。
-
width: 100%永远只参考父元素的 content box，不包含 padding/border - 移动端 viewport 缩放、DPR、meta 标签缺失都会让“100%”的基准失真
- 某些 UI 框架（如早期 Ant Design）内部用了
100vw，和width: 100%混用时容易冲突
常见错误组合：padding + 100vw + 默认box-sizing
很多人写width: 100vw本意是“占满屏幕”，但一加padding: 20px就溢出。这是因为100vw是视口宽度，padding是额外加在它外面的——总宽 = 视口宽 + 左右 padding。哪怕你写了box-sizing: border-box，它也只管padding和border，不管margin或100vw本身的膨胀。
- 错误写法：
width: 100vw; padding: 20px;→ 必然溢出 - 正确替代：
width: 100%; padding: 20px;，并确保父容器有明确宽度（比如html, body { width: 100%; }） - 更稳妥：
width: calc(100% - 40px); padding: 20px;，把 padding 预扣掉
第三方库或框架引入的隐藏宽度源
像 Tailwind、Ant Design 这类库，部分组件默认用100vw或min-width: 100%，而它们的 wrapper 容器可能没设overflow-x: hidden。一旦里面塞了长文本、代码块或未设table-layout: fixed的表格，整行突然拉宽，width: 100%就守不住边界。
立即学习“前端免费学习笔记（深入）”；
- 查 DevTools 的 computed width，看
width: 100%到底参考的是哪个父元素 - 对表格、代码块这类“硬撑型”内容，优先加
min-width: 0或overflow-x: auto包裹层 - Tailwind 用户注意：
w-full等价于width: 100%，但它不解决父级无约束的问题
真正容易被忽略的一点：viewport meta 和 body 默认 margin
很多项目漏了<meta name="viewport" content="width=device-width, initial-scale=1">，或者没清body的默认margin。结果width: 100%算的是body内容区，而body自己还带 8px margin —— 这 8px 就成了横向滚动条的根源。
- 必须加：
html, body { margin: 0; width: 100%; } - 必须加 meta 标签，否则 iOS Safari 会按桌面视口渲染
- 不要依赖全局 reset.css 里的
* { margin: 0; }，有些框架会覆盖它
