移动端适配落地避坑实录

上周三凌晨两点改完最后一行代码。

浏览器一开，傻了。

客户那边刚发过来的截图，用最新的折叠屏手机打开我们做的618活动页，左半屏堆着所有的商品卡片，右半屏空着能跑马，连最底部的立即抢购按钮，直接卡在了屏幕折痕的位置，点都点不准。

说起来也是好笑，我们当时拍胸脯说适配方案早就调好了，用的是业内最通用的rem方案，结果栽在了没人提前想到的折叠屏场景里。

别上来就套rem方案

我知道很多前端新人刚入行，学的第一套适配方案就是淘宝早年开源的flexible，改个基准值就能通吃所有移动端设备。但真的用在实际项目里，坑多到你想不到。

去年接的一个政企定制项目，客户要求必须适配他们内部配发的10寸定制平板，宽度只有800px，dpr却做到了2.5。我们当时没改基准值，还是按750px设计稿的比例算font-size，结果上线之后客户反馈，页面上的标题文字直接大到溢出容器，连导航栏的菜单都折成了三行。

不要直接抄开源库的默认配置，这话我跟组里的新人说了不下十次。现在的设备品类早就不是五六年前只有手机和普通平板的状态了，折叠屏、带鱼屏、小屏老人机，各种奇奇怪怪的尺寸都有，你拿着五六年前的适配方案往现在的项目上套，不出问题才怪。

不同移动设备视口尺寸对比表

说穿了，rem方案本质上是按屏幕宽度等比例缩放所有元素，适合那种内容排版完全跟着宽度走的运营活动页，但遇到需要固定尺寸的弹窗、表单输入框，反而会因为缩放导致元素比例失调，还不如直接用px写死来得稳妥。

谁懂啊，去年做的一个电商H5，上线第一周就被投诉了三百多单，原因是苹果底部的home指示条挡住了提交订单的按钮，用户点十次有六次是误触退出。

当时网上随便搜搜就能找到解决方案，给body加个env(safe-area-inset-bottom)的内边距就行。我们照做了，结果安卓那边的全面屏手机，底部手势导航的高度比苹果多了12px，页面底部直接空了一大块白边，看起来像没做完的半成品。

安全区域的值要分设备做兼容，不能一套代码通吃所有系统。苹果的安全区域值是系统自动算的，但安卓各家厂商的手势导航逻辑完全不一样，有的是固定高度，有的是动态调整，你要是直接把苹果的代码抄过去，迟早要出问题。

我现在处理安全区域的逻辑，都是先判断设备的操作系统，苹果端直接用系统提供的env值，安卓端就单独加个适配的内边距，哪怕多写几行代码，也比上线之后被用户骂强。

很多设计师给的设计稿，永远只有两个尺寸：375px的手机端，750px的平板端。你拿着这两个尺寸做适配，中间跨度大到离谱的那些设备，全是bug重灾区。

之前组里有个刚毕业的同事，直接按设计稿的375px宽度写死了导航栏的margin，结果在小米那款小屏老人机上，导航栏的五个按钮直接折成了两行，把首屏的banner挤下去了三分之一，用户打开页面根本看不到最核心的活动信息。

还有人喜欢抄网上的通用断点，说768px以下是手机，以上是平板。但你仔细算下自己页面里的内容，两列的商品卡片在600px宽度的时候就已经挤得放不下了，你非得等到768px才换成单列布局，中间那168px的宽度区间，用户看到的全是挤变形的卡片。

断点要跟着自己的内容走，不是跟着网上的通用尺寸走。我现在定断点之前，都会先把页面的内容拖到不同宽度的窗口下，看看到底哪个尺寸下内容会挤变形，就把断点设在哪里，再也不瞎抄别人的数值了。

真的怕了。

之前踩过的所有坑，说穿了都是把网上的通用方案当成了银弹，总觉得别人用着没问题，自己直接抄过来也不会出问题，却忘了自己的业务、自己对接的设备池、自己的设计稿细节，跟别人的项目根本不是一回事。