「横屏我们测过了」——测的是横屏打开，不是中途转屏

展会第二天下午，销售把手机横过来递给客户看产品参数。页面在那一瞬间重排成了两栏，左边是导航列表，右边是参数表格。这套两栏布局本来是给平板准备的，此刻却被压进一块高度只剩三百出头的可视区里。客户手指划了三下，看到的还是表头，销售把手机收回去，改用微信发了张截图过去。

回去翻验收记录，横屏这一项是打过勾的。测试同事确实测了：把手机横过来，打开网址，截图，页面完整、不错位、不溢出。问题在于测的是「横屏打开」，而现场发生的是「竖着用着用着转过去」。这两件事在浏览器里走的不是同一条路，前者只经历一次渲染，后者要经历一次重排、若干次尺寸重算，以及页面上所有已经存在的中间状态被迫迁移。

三条路先摆在台面上

横竖屏这件事，实际项目里能选的做法就三条，投入差得很远。

第一条是劝回竖屏。检测到宽大于高就盖一层半透明遮罩，中间放个旋转手机的图标，下面写一行提示。代码不到五十行，含调试半天做完。网页制作的报价单上这一项通常不单独计价，被含在移动端适配那一栏里。

第二条是不做处理，让横屏自己落进已有的宽屏断点。零额外投入，零额外周期。手机横过来之后视口宽度变成六百多到九百多之间的某个值，正好命中当初为平板写的那套媒体查询，页面就按平板的样子渲染出来。

第三条是给横屏单独定规则。用方向或宽高比媒体查询挂一套覆盖样式，给表格、图册、视频、长表单这几类模块各自指定横屏下的行为，再补上转屏时的重算逻辑。按一个二十页左右的企业站算，样式加逻辑三到五人日，真机回归测试还要再加一到两人日。

报价单上不会写的那部分

第一条路最大的问题是它其实做不到。浏览器提供的方向锁定接口在移动端基本不可用，iOS 上的 Safari 和微信内置浏览器都不支持网页强制锁定方向，安卓上也只在全屏或已被安装成应用的场景下才生效。所谓锁定竖屏，在网页里只能退化成一层遮罩，用户仍然横着拿手机，只是被挡住了。

更麻烦的是被挡住的是谁。装着键盘保护套的平板，打开页面时默认就是横屏，把手机卡在支架上的人是横屏，因为视力原因习惯横屏放大字号的人也是横屏。他们看到的第一屏是一张请你转过去的提示图。无障碍规范里有一条专门约束这件事，要求内容不得被限制在单一显示方向，除非该方向是内容本身所必需，比如虚拟钢琴键盘。企业官网显然不在此列。这条不会出现在报价单上，却会出现在稍大一点的客户方 IT 部门的检查表上。

第二条路的问题是断点撞车。常见手机横过来之后，视口宽度大致落在六百六十七、七百三十六、八百四十四、八百五十二、九百三十二这几个值上，而为平板写的媒体查询区间通常是七百六十八到一千零二十四。于是横屏手机拿到了平板的两栏布局，可用高度却只有三百上下：竖屏时八百四十四的高度装两栏内容绰绰有余，横屏时高度变成三百九十，再扣掉系统占用的四十四左右和自己做的吸顶导航，留给内容的部分连一屏都算不上。布局是对的，比例是错的，而截图看起来没毛病。

第三条路的成本也不在明面上。写那套横屏样式本身不难，难的是它把测试矩阵从几个页面，变成几个页面乘以两个方向再乘以若干中间状态。网页制作里真正吃工时的往往是这种乘法，而不是单个页面的工作量。更长期的开销是纪律：以后每加一个模块都得转一次屏，这句话写不进合同，只能靠流程卡住，而流程是项目上线三个月后最先松掉的东西。

漏测场景一：表单填到一半把手机转过去

这是所有转屏问题里最贵的一个，因为它直接掉转化。一个已经填了六个字段的询价表单，用户为了看清楚某个长下拉把手机横过来，可能同时遇到三件事：输入焦点丢失、软键盘收起后滚动位置错乱、以及在部分安卓环境里已填内容被清空。前两件是浏览器行为，第三件多见于把网页嵌进原生壳的场景，安卓页面容器在方向变化时会重建，如果没有声明相应的配置项，整个页面等于被刷新了一次。

三条路在这里的表现值得摆在一起看。遮罩方案表面上躲开了，实际只是把人拦在遮罩后面，他转回竖屏时同样触发一次方向变化，该丢的还是丢。不做处理的方案会把三个问题原样暴露。单独定规则的方案能解决布局错位，但如果没有额外做输入值的暂存，第三件事一样躲不掉。真正的解法与横屏样式无关：把表单值随输入写进本地存储，页面初始化时回填，这段逻辑大概三十行，却是转屏、误触返回、意外刷新三种事故的共同保险。

漏测场景二：键盘弹着的时候转屏

这个场景会同时打穿第二条和第三条路，原因藏在媒体查询的判定规则里。横屏这个条件的判定标准是视口宽度大于视口高度，而不是设备真的转了。竖屏手机弹出软键盘后，如果页面处于视口会被压缩的模式，可视高度会从六百多掉到三百上下，一旦低于宽度，浏览器就认定进入了横屏，为横屏写的那套样式突然生效——用户明明竖着拿手机，页面却变成了两栏。这类问题的报障描述往往是「一点输入框页面就乱」，很少有人会往方向判定上想。

规避办法有两个。一是不用方向条件，改用宽高比判定，阈值设在十三比九附近，键盘引起的高度变化通常达不到这个比例。二是读取屏幕方向对象拿到设备真实朝向，与媒体查询做双重确认。顺带要处理的是横屏加键盘的极端情况：横屏时可视高度本就只剩三百左右，键盘再吃掉一半以上，留给内容的高度只有一百五到一百九，此时任何固定在底部的提交按钮都会盖住输入框本身。可行的做法是检测到可视高度低于两百四，就把固定定位改回文档流，让按钮乖乖排在表单末尾。

漏测场景三：有东西正开着的时候转屏

页面上存在中间状态时转屏，是截图式验收永远发现不了的一类问题。常见的有四种。展开的下拉菜单和日期选择器，转屏后仍按旧坐标定位，浮到了屏幕外面。全屏弹层的高度写死成视口高度，转屏后内容超出而内部没有滚动，底部那个确定按钮点不到。地图和图表容器需要手动触发一次尺寸重算，不做就会被拉伸变形，坐标轴文字叠成一团。播放中的视频在部分安卓内核上会重新加载，进度归零，已经缓冲的流量白花。

处理这些有个前提，就是拿到方向变化的正确时机。传统的方向变化事件在触发那一刻读到的窗口尺寸往往还是旧值，所以老代码里经常见到延迟三百毫秒再执行的写法，能用但不可靠。更稳的方式是监听媒体查询自身的变化事件，再配合容器尺寸观察器，让每个需要重算的组件响应自己容器的变化，而不是全站共用一个方向回调。这两种写法的差别在出事的时候才看得出来：前者出错只影响一个模块，后者出错是整页一起错。

漏测场景四：从来就没竖过的那些设备

还有一类访问从进门起就是横屏，占比常被低估。带键盘保护套的平板、车机屏幕、会议室里的一体机、固定在展台上的样机，默认方向都是横的。它们的共同特征是宽度不小但高度有限，而且不少是通过第三方内核访问，与手机横屏的表现并不一致。

这里有个能直接改变判断的事实：微信在 iOS 上的内置浏览器默认不跟随系统旋转，用户要自己去设置里打开横屏模式，安卓端的微信则跟随系统。如果一个站点八成以上流量来自微信分享，那么 iOS 侧的横屏访问量会远低于行业均值，第三条路的性价比就要重新算。反过来，如果流量里平板和外部浏览器占比高，横屏就是网页制作里必须认真做的一档。这个比例不需要猜，流量统计后台里按设备类型和屏幕分辨率两个维度交叉一下，十分钟就能拿到自己站点的真实数字，比任何经验值都可靠。

把转屏写进验收单，而不是写进备注

验收清单是网页制作交付物里最容易被简化的一份文件，横竖屏又恰好属于不写就一定不测的那类项。可以直接照抄的写法是把动作而不是结果写进去：在首页向下滚动到第三屏之后转屏，看滚动位置是否还停在同一段内容上。在表单填入三个字段之后转屏，看已填内容和输入焦点还在不在。打开一个弹层之后转屏，看还能不能关掉。视频播放十秒之后转屏，看进度有没有归零。横屏状态下点击输入框唤起键盘，看提交按钮是否仍然可见。转屏之后再转回来，看页面能否回到转屏之前的样子。六条，一台真机走完不超过八分钟，比任何一句兼容主流移动设备都管用。

什么条件下走哪一条

第一个要看的数字是横屏访问占比。低于百分之三，第二条路是理性的，把预算挪到别处去。超过百分之十，第三条路的投入通常几个月内就能从跳出率上收回来。这个数字每个站点差异极大，不要用别人的。

第二个要看的是页面里有没有宽度敏感的内容。超过五列的表格、需要对照阅读的图纸、横向时间轴、代码块，这些东西在竖屏下本来就难用，用户转屏是合理需求，此时用遮罩劝返等于赶客。反过来，如果全站只有文字和图片，横屏无非是行宽变长，第二条路加一条最大宽度限制就够了，成本是一行样式。

第三个要看的是页面上有多少个可以「开着」的东西。弹层、下拉、播放器、地图、轮播，每多一个，第三条路要处理的重算点就多一个，同时不做处理时的风险也多一分。数到三个以上，就别指望靠现有断点蒙混过关。

三条路里唯一不该单独存在的是第一条。遮罩可以做，但只能做成可关闭的提示条，而不是一堵墙——一句「这个页面竖屏读起来更方便」加一个关闭按钮，成本和遮罩一样，却把决定权还给了用户。至于网页制作合同里该怎么约定，把上面那六条验收动作原样附进去就行，比十行兼容性描述有用得多，也让双方在出问题时有个共同的判断口径。