移动端适配一线踩坑笔记

上周接了朋友的求助，他做的一个美妆活动页，自己用最新款iPhone测了三遍都没问题，结果上线半天就收到一堆用户骂。

有人说打开之后领券按钮直接伸到屏幕外面，点都点不到；有人说用的是小屏安卓，两行字挤成一团，连活动规则都看不清。

我打开自己抽屉里压了三年的红米5Plus试了下，好家伙，整个页面直接溢出半屏，连顶部的导航条都歪到一边。

最常见的坑根本不是屏幕尺寸

很多人一听到适配出问题，第一反应就是补media query，对着不同分辨率的屏幕写对应的样式。

没用的。

现在市面上光主流的安卓机型分辨率就有上百种，更别说还有各种定制ROM改了默认字体大小、改了状态栏高度，你就算把所有参数列成表格挨个写样式，总有漏网之鱼。

之前我们团队做的社区线下活动报名页，测试的时候拿iPhone14和小米13跑了所有流程都顺，结果上线第一天就收到200多条反馈。用折叠屏的用户打开，侧边的报名按钮直接被折痕挡住一半；用曲面屏的用户，输入框的提示文字直接被边缘切掉一截。

真正的适配从来不是追着每一种屏幕尺寸写media query。我见过最夸张的前端，光针对安卓的适配样式就写了400多行，最后还是被用户截图骂——那是个把系统字体调到最大的老年用户，整个页面的文字大到占满半屏，提交按钮直接被挤出可视区域，连页面底部的联系方式都看不见。

别再把适配等同于“适配不同屏幕”了，你要适配的从来不是冰冷的尺寸参数，是不同用户手里的真实使用环境。

那些没人提前说的落地细节

我现在做项目，上来不会先写组件，先把基础的适配规则定死。

别用写死的1rem等于16px的套路。很多人用postcss-pxtorem的时候，拿着设计稿的尺寸直接除以100，根本不考虑大屏下的显示效果。之前有个新同事做的资讯详情页，就是这么干的，结果在iPad上打开，字大到一行只能放8个汉字，行间距拉得比字还宽，读着特别累。

相对单位一定要配最大宽度阈值。比如文章容器最多到1200px就不再拉伸，两侧留均匀的空白就行，别硬撑满整个屏幕——你总不能让用户在27寸的显示器上读一篇手机端的文章，头歪来歪去找行吧。

还有那个被人说烂的安全区。很多人写viewport标签的时候，总忘了加viewport-fit=cover，结果iPhone底部的系统横条直接挡住提交按钮。这个坑我踩过不下十次，每次新同事做活动页都要忘。别觉得这是小问题，之前我们做的付费会员活动，就是因为提交按钮被底部横条挡住，整整3个小时的转化率只有平时的1/5，最后整个组的人都挤在会议室盯着后台数据，冷汗都下来了。

对了，别把所有元素的边距都设成相对值。比如弹窗的关闭按钮，你要是设成相对于屏幕宽度的大小，在小屏手机上它会小到根本点不准，在折叠屏上又会大到挡了半屏内容。这种固定交互元素，该写死px就写死，别为了“适配”硬套相对单位。

别把所有适配的锅都甩给前端

说个特别气人的事。之前有个产品经理提需求，就甩了一张按iPhone14尺寸做的设计稿，说“按这个做，所有手机都要显示得和设计稿一模一样”。

我当时直接把之前老年用户的反馈截图甩给他。你要的一模一样，就是字挤成一团，按钮点不到，对吧？

适配从来不是前端一个人的事。设计阶段就得考虑弹性布局的可能性：按钮的宽度能不能自适应，文字多的时候会不会换行，别给一个固定宽度的按钮，写死里面放“立即领取100元新人券”——万一用户把字体调大，字直接溢出来，你总不能让前端给每个按钮加个文字截断的属性吧？

测试环节更是别偷懒。很多团队测适配，就拿两款最新的旗舰机走一遍流程，连横竖屏切换都忘了试。我们现在组里专门留了几个“古董”：iPhone SE、三年前的红米、还有一个折痕很深的折叠屏，每次版本上线前必过一遍流程，哪怕多花半小时，也比上线了收到一堆投诉，连夜爬起来改代码强。

上周帮朋友改完那个活动页，他给我发了个奶茶红包。

我点开看，也就18块。

值了。

毕竟谁没在凌晨三点爬起来，改线上适配bug的经历呢。