放大后不应产生双向滚动
别名: 双向滚动 · 横向滚动 · two-dimensional scrolling
概念解释
文本放大之后，读一段连续正文应当只沿一个方向滚——通常是纵向。既要左右推、又要上下推才能拼完一行，就是双向滚动。失败的不是「出现了滚动条」，而是阅读窗口变成一块要在平面上平移的钥匙孔。低视力用户的可视范围已经很小，再加一条轴，工作记忆里拼句子的成本会陡增。
机制
视口是有限矩形。字变大后若布局仍坚持原来的最小宽度，文档宽度超过视口，纵向滚再叠加整页横向滚。人读行是从左到右再回到下一行行首；横向偏移一旦不归零，下一行要对准就得来回找。这和「某个部件自己内部可以横滑」不是同一件事：表格、代码块、地图可以在局部提供二维平移，只要它不把整页 body 撑出横向滚动。
一个英雄图、一条不换行的宽表、一个 min-width: 1200px 的栅格，就足以让整页变成二维画布。字还在、也没被裁切，但获取方式坏了——所以「没丢内容」过了，仍可能在这一条上失败。更高倍数下改成单列、避免靠横滑读正文，是另一组更严的重排要求；本组先卡住「检查点上不要整页双轴」。
怎么研究
放大到 200% 后比较 scrollWidth 与 clientWidth，并实际读完一篇段落：中途要不要左右平移。把「部件级横滑」和「文档级横滑」分开记。
自变量：放大倍数、页面最小宽度、是否存在不收缩的宽部件。 因变量：文档是否出现横向滚动、读完一段需要的平移次数、用户是否丢失行首。
键盘用户没有触控板惯用的斜向拖，更暴露双轴代价。不要用「把窗口拉得很宽」来消除失败——检查视口应接近产品声明的最小宽度。
边界
数据表、乐谱、地图、绘图画布作为明确的二维介质，允许在自身盒子里双轴移动，前提是周围正文仍单轴。移动端本来就窄，放大后更容易整页横溢，不能拿「手机本来就能横滑」当合格。用户主动把窗口缩到极窄，超出声明视口的，不算产品失败。浏览器整体缩放与只放字号两条路径会把不同的横向溢出暴露出来，要分开测，但判据同为「读正文不要双轴」。
怎么落地
- 栏宽用
%/max-width: 100%/ 可折列，不要给整页设死的大min-width。 - 必须很宽的部件（表、代码、画布）包在自己的滚动盒里，不要让它撑开
body。 - 长 URL、不换行代码、白空格预排要允许折行或只在部件内横滑。
- 验证：在声明的最小视口把文本放到 200%，正文段落从头读到尾，手不准左右推。整页出现横向滚动条即失败；仅表格内部有横滑则记下部件名，不判整页失败。