上周大促前12小时，运营小姑娘甩过来一张糊不拉几的截图。
图里的领券按钮，半个身子躲在红米Note7的系统虚拟导航栏后面，点都点不到。
真的会谢。
全组人瞬间后背发凉。毕竟为了这个活动页，我们前前后后调了快两周的样式，测了十几台主流旗舰机，从来没碰到过这种问题。
被你忽略的适配重灾区根本不是主流机型
很多人做移动端适配，第一反应是对着最新的旗舰机调样式，iPhone 15的尺寸、小米14的分辨率，拉出来挨个对齐。
错得离谱。
我们翻了过去半年的用户访问日志，有17%的用户用的是发布超过3年的旧机型，屏幕物理宽度不到360px。还有近一成的用户，把系统字体放大到了最大档位——这个比例比你想象的高得多。
上次碰到个用户，拿着开了200%字体的旧安卓机打开我们的内容页，设计稿上单行放得下的18px标题，直接撑成了三行，把下面的点赞按钮挤到了屏幕可视区外面。他在评论区留了一句”字都看不全，做的什么垃圾页面”，我们追了半天才找到对应的bug。
别觉得这些用户是少数。你多看看自己的后台数据就知道，那些花了大精力优化的旗舰机体验，可能只覆盖了不到一半的访问用户。
别再把rem当成适配的万能解
前几年做适配，大家都爱用flexible+rem的方案，算好根字号，所有元素按比例缩放就行。
现在这套真的不够用了。
上次有个用华为Mate60的用户反馈，我们的页面在他的高清显示模式下，根字号算出来直接比设计稿大了12%，所有的留白全挤没了，按钮之间连个缝隙都没有。还有的老机型webview版本太旧，根本不认这套计算逻辑，算出来的字号飘到没边。
我们现在团队定了几个死规则，不管什么方案都要卡死：
所有可交互元素的最小点击区域，绝对不能小于48px。哪怕屏幕再小，这个尺寸不能动，不然用户戴着手套或者手滑的时候，根本点不准。
所有页面元素的左右安全边距，至少留16px。碰到曲面屏、打孔屏的机型，再加一层safe-area的适配，用env(safe-area-inset-bottom)把底部被系统导航栏挡住的空间留出来。
还有图片的适配，别直接给img标签写死width:100%。之前我们吃过亏，地铁里信号差的时候，图片慢慢加载，直接把页面撑得左右乱晃，用户滑都滑不动。现在我们的banner图全是服务端按屏幕宽度切好的，360px的屏给720px宽的图，414px的屏给828px的图，省流量还不会乱撑布局。
真正的适配从来不是前端一个人的事
之前我们总觉得适配是前端的活，设计出什么稿，我们就照着写什么代码。
直到上次跟设计部掰扯了半小时才想通：设计稿上如果把一行字的宽度卡得刚好，用户开了大字体之后，直接就溢出了。后来我们跟设计定了规矩，所有文字模块，必须留至少两行的溢出空间，不能按单行满打满算排。
测试环节也是一样。之前我们的测试机库里全是最新的旗舰机，测来测去都是一样的体验。现在我们专门留了三台”古董机”：用了四年的红米Note7，iPhone8，还有一台折叠屏旧款。每次发版前，这三台机器必须跑一遍全流程，有没有按钮被挡，有没有文字溢出，有没有图片变形，一个都不能漏。
说实话，之前我也觉得移动端适配是个没技术含量的体力活，不就是调调样式嘛。直到上次大促因为那个被挡住的领券按钮，算下来少了快20万的券核销，才明白这些看起来细碎的小调整，真的能直接影响到业务结果。
不过话说回来，现在的前端框架已经帮我们挡了大部分低级坑，比如响应式布局的工具，内置的安全区适配组件，但是你要是完全不碰底层的逻辑，真出问题的时候，你连去哪找bug都摸不着头脑。上次我们碰到个小众安卓机的bug，fixed定位的元素直接跟着页面滚走了，查了半天才知道是那个机型的webview太老，不支持最新的fixed属性，最后打了个补丁才解决。
其实哪有什么一劳永逸的适配方案啊。无非就是多站在用户的角度想想——他可能拿着用了三四年的旧手机，可能在信号差的地铁里刷页面，可能眼睛不好开了最大的字体。你把这些细碎的场景都考虑到，比写多少华丽的媒体查询都管用。
上周我们又给所有活动页的领券按钮多留了8px的安全距离。现在不管是老红米还是新折叠屏，按钮都安安稳稳待在用户能轻松点到的地方。