左右白边是viewport配置、默认样式与渲染精度三者叠加失效所致；须组合设置maximum-scale=1.0、user-scalable=no等meta属性，并重置body margin、box-sizing及overflow，grid中避免小数gap与fr精度误差。
直接结论：左右白边不是缩放比例没校准，而是 viewport 配置 + 默认样式 + 渲染精度三者叠加失效的结果；单独调 initial-scale 几乎无效，必须组合修复。
为什么 initial-scale=1.0 无法消除白边
移动端浏览器（尤其是 Safari 和基于 WKWebView 的微信/支付宝）在双击、手势拉伸或软键盘弹出后，会进入临时缩放态，此时 initial-scale 已不生效。更关键的是：initial-scale=1.0 不等于“禁止缩放”，它只设初始值——若漏掉 user-scalable=no 或 maximum-scale=1.0，用户操作后页面就会残留非整数缩放因子，导致小数像素渲染错位，Grid 或 flex 容器边缘对不齐视口边界，露出白边。
- 仅写
width=device-width, initial-scale=1.0是常见错误起点 - 安卓 WebView 对
initial-scale解析更宽松，但 iOS 会严格保留缩放态，影响后续所有布局计算 - 即使 JS 动画已停用，白边仍存在，说明问题根植于 CSS 渲染链底层
必须写的 viewport meta 配置
以下 <meta> 是最小可行集，缺一不可：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, viewport-fit=cover">
-
maximum-scale=1.0比user-scalable=no更兼容可访问性需求（允许双击放大一次，但阻止持续拉伸） -
viewport-fit=cover仅在需要全屏沉浸式体验时启用；若只是普通 H5，删掉它，避免触发 iOS 安全区重算逻辑 - 绝对不要混用已废弃的
target-densitydpi，它会让部分 WebView 忽略整个content字符串
body 和容器的 CSS 校准动作
viewport 只是第一道防线，真正撑出白边的是浏览器默认样式和盒模型偏差：
- 所有浏览器都给
设了margin: 8px，这 16px 水平空间在缩放后会被放大，成为白边源头 - 未声明
box-sizing: border-box时，padding和border会额外加到width: 100%之外 -
overflow-x: hidden必须加在body上，且不能只加在某个子容器——溢出可能来自任意层级
推荐基础重置（放在 CSS 最顶部）：
body { margin: 0; padding: 0; box-sizing: border-box; overflow-x: hidden; }
html { overflow-x: hidden; }
Grid 布局下白边的精度陷阱
当使用 grid-template-columns: repeat(3, 1fr) 时，视口宽度如 375.33px 除以 3 得到非整像素（125.11px），各列四舍五入误差累加，第三列右边缘常超出视口 1–2px，触发横向滚动并暴露白边：
- 改用
repeat(3, minmax(0, 1fr))，让浏览器有裁剪余量 - 避免
gap使用小数rem（如gap: 0.6rem），iOS Chrome（WKWebView）对此解析不稳定；优先用整数px或clamp(8px, 2.5vw, 16px) - 若父容器 font-size 动态变化（如媒体查询切换），
remgap 会因基准浮动而偏移，这是最隐蔽的白边来源之一
真正难缠的白边，往往藏在 gap 小数计算、body 默认 margin、以及 viewport-fit=cover 启用后却忘了配 env(safe-area-inset-*) 这三者的交叉点上——单点修复容易漏掉其中一环。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
