移动端适配一线落地的真实门道

上个月做618大促的活动页，我刚啃到一半的煎饼果子还没咽下去，运营的微信就弹了满屏的未读——安卓折叠屏打开页面，主报名按钮直接飘到屏幕右边缘，离安全可点击区差了快20px，用户点了三次都没反应，已经有十几个在评论区骂街了。

我当时手忙脚乱开电脑改代码，改到一半才反应过来，这个坑我们踩过多少次了。

那些藏在细节里的适配盲区

很多人觉得移动端适配就是写个几行CSS的事，根本没把它当正经的技术工作。设计出稿的时候默认所有用户的屏幕都是375px宽度，写代码的时候默认只要能在自己的iPhone上显示正常就算完事，等上线了才发现，刘海屏挡住了顶部的导航栏，老安卓机上的文字挤成一团，折叠屏打开之后整个页面的元素稀稀拉拉铺在半块屏幕上。

哦对了，上次那个折叠屏的问题，我们最后改的时候，直接把原来的固定宽度的按钮容器改成了max-width:500px，在大屏上自动居中，小屏上自动撑满，就这么几行代码的事，之前居然没想到。说白了就是做的时候根本没站在用户的角度想过，他手里的屏幕到底是什么尺寸。

别把rem方案当万能解药

我见过太多团队，从五六年前开始用rem方案，引入lib-flexible库，把375px设计稿上的所有尺寸都按比例换算成rem，就觉得适配工作已经做完了。

真的不是。上次团队的新人写活动页，把14px的正文字号直接换算成0.373rem，结果在320px宽度的老安卓机上，实际渲染出来的字号才11px，我把截图发给设计看的时候，设计说这字小的他要把眼镜推到额头上才能看清。

有人说那换vw总行了吧，100vw就是屏幕宽度，算起来更直接。可你算过横屏的情况吗？竖屏时候的375px宽度，一旋转变成横屏，原来的banner图直接被拉成细条，人物的脸都被挤变形了。

别信网上那些说rem已经被淘汰的言论，方案本身没有错，错的是用方案的人——你要是把所有元素包括字号都按比例缩，那不管用什么方案都做不好。我之前见过最离谱的代码，是把所有按钮的位置都写死了left:300px，不管什么屏幕都硬放，我当时盯着屏幕看了半分钟，真的想给写这段代码的兄弟递瓶冰可乐，问问他是不是上周才从PC端切到移动端的。

上线前必须卡的三个检查节点

别总想着等线上出问题了再补bug，适配工作真的没那么复杂，把几个关键节点卡牢，能省掉80%的麻烦。

别只盯着最新款iPhone测。我们团队现在专门有个测试机抽屉，从老款的iPhone SE（320px宽度）到最新的折叠屏（768px展开宽度），每次上线前前端自己先划三遍，把竖屏、横屏、深色模式的状态都过一遍。之前我们省这个事，只在自己的工作机上测，结果线上出了三次老机型的布局错位，每次补bug都要花两个小时，还不如提前十分钟测完省时间。

把安全区适配写进全局组件。别每次写新页面的时候才想起来加viewport-fit=cover，也别每次都手动给顶部加env(safe-area-inset-top)的内边距，直接把这些逻辑写在公共的布局组件里，所有页面自动继承，省得哪个页面漏加，返回键被系统的状态栏挡住。上次那个被投诉的政务页面，就是因为写代码的时候忘了加这个属性，顶部的返回键直接被刘海挡了一半，用户点了半天退不出去，差点打12315投诉。

核心交互元素别跟着屏幕等比缩放。正文的字号最低不能小于14px，可点击的按钮高度不能低于44px——这不是什么死板的规则，是之前我们做过测试，把按钮从36px调到44px之后，活动页的点击率直接涨了12%，当时产品在群里发了二十块钱的拼手气红包，我抢到了三块二，那天加班的外卖特意加了个卤蛋。

不过话说回来，我上周在技术群里还看到有人吵，说适配根本没必要做这么细，大部分用户都用主流机型，那些用老安卓、用折叠屏的用户本来就不是目标客户。

这话听着就来气。上次那个打投诉电话的用户，是我们在平台上充了三年会员的老用户，就因为页面挡了个返回键，差点要退会员。

其实移动端适配哪有什么高深的技术啊，说白了就是别总坐在办公室里，拿着自己手里的最新款手机，就默认所有用户的屏幕都和你的一样。你多花十分钟在不同的设备上划两遍，少写几行偷懒的硬编码，比你上线之后花三个小时回应用户投诉强多了。