上周六被前同事拽去改他们刚上线三天的生鲜小程序。
我刚点开首页就差点把手里的冰美式泼到键盘上——首屏的banner被硬生生切掉右半块，加购按钮顶在屏幕边缘连个边距都没留，连搜索框弹出来的时候，直接被系统键盘挡得严严实实，连输入的光标都看不见。
他们的开发还委屈，说我明明加了viewport啊，怎么会出这种问题。
真的。
太多人把移动端适配想得太简单了。
别拿viewport当万能解药
很多人对适配的全部认知，就是在head里加一行，加完就觉得万事大吉，所有px尺寸随便往页面上堆。
就像这个生鲜项目的商品卡片，开发写死了width: 300px，在他自己用的iPhone14上刚好铺满一行，结果拿到iPhone SE上直接超出半块屏幕，在用户手里的折叠屏展开状态下，又缩在屏幕左边留了一大片白花花的空白，连个自适应的宽度都没设。
更离谱的是，他们连最基础的屏幕密度适配都没做，图片用的全是72dpi的普通图，在高DPI的安卓机上直接糊成马赛克，用户点进去看商品详情，连水果上的轮廓都看不清。
我当时跟他说，viewport只是让页面按照设备宽度渲染的基础开关，根本不是适配本身。你总不能装了个开门的开关，就说自己把整个房子都装修完了吧？
那些没人提前说的适配细节
改这个项目的过程里，我光补的细节就列了满满一页便签。
第一个要改的是操作热区。那个小程序的数量减号按钮，做的只有24px见方，我自己手指不算粗，点了三次才中一次。移动端的可点击元素，最小尺寸必须留够44px见方，这不是什么审美要求，是用户的操作底线——你做的再好看，用户点不动都是白搭。
紧接着是安全区。他们的底部导航栏，刚好被iPhone的Home指示条挡住一半，用户点“我的”的时候经常误触直接退回桌面。这个问题改起来其实特别简单，只要给固定在底部的元素加个padding-bottom: env(safe-area-inset-bottom)就行，就这一行代码，他们之前居然完全没考虑。
还有那个输入框被键盘挡的问题，很多人以为是系统的锅，其实只要监听键盘弹起的事件，把当前的输入框自动滚动到可视区域内就行，不用让用户自己手动滑屏幕找光标。
哦对，还有字体的问题。他们之前用rem做适配，根字体写死了16px，在大屏安卓上，标题直接拉成两行，把本来就不大的商品图挤得只剩三分之一，用户扫一眼根本看不到商品长什么样。后来我们改成了断点适配，在360px以下的屏幕缩小根字体，768px以上的平板设备再适当放大，整个布局立马就顺了。
说实话，这些都不是什么高深的技术，就是没人提前说，没人愿意在写代码的时候多花五分钟考虑一下不同设备的情况。
别把适配留到上线前最后三天
别不信。
我见过太多团队的流程，适配永远是排期里最边角的那项，开发把所有功能写完，测试最后三天才抱着一摞机型挨个点，问题堆成山了再临时抱佛脚改。
这个生鲜项目就是，他们之前排期的时候，适配只留了1天的时间，结果我们整整改了三天，还漏了好几个小众安卓机型的状态栏适配问题。
适配根本不是最后补窟窿的工作。
从设计阶段就要介入——设计师出稿的时候，就要标清楚不同断点的布局逻辑，360px以下的小屏怎么排元素，768px以上的平板或者折叠屏展开的时候怎么利用多余的空间，而不是把所有问题都丢给开发“你看着调”。
开发阶段也要养成习惯，别总盯着浏览器的模拟器看。那玩意是理想状态的假设备，真实的小米机会把状态栏叠在页面顶部，华为的折叠屏展开的时候会毫无征兆的触发宽度变化，甚至还有那种带挖孔屏的机型，挖孔刚好挡在页面的标题上——这些问题，模拟器里根本模拟不出来。
我现在做项目，第一天就把手里的旧SE、公司测试机的红米、还有自己的折叠屏都摆桌上，改一会就刷上去划两下，省得最后补窟窿补到凌晨。
上次那个生鲜小程序改完上线之后，之前占投诉量20%的“按钮点不动”“页面错位”的问题，直接降到了0.2%。
这种实实在在的用户反馈，真的比写一堆架构文档爽多了。
改完之后我才发现，我那天的冰美式一口都没喝。