移动端适配远不止写媒体查询那点事

上周跟电商部的老陈蹲在公司楼下抽烟，他烟都抽完半根了还在骂，说上周刚上的品类日活动页，安卓端某品牌的千元机打开，领券按钮直接叠在商品价格数字上，用户点了半天要么领不到券要么跳错链接，当天客诉直接干到327条，整个运营组从下午两点改到凌晨三点，眼都红了。

你以为的适配和真实的适配根本不是一回事

很多刚入行的前端会觉得，移动端适配不就是写几个@media查询，把容器宽度设成100%，再用rem换算下单位就完事？ 哪有那么简单。 我刚工作那会也抱着这种想法，当时接了个本地餐馆的官网单子，测了自己的iPhone13和公司配的红米测试机，点了三圈觉得没问题就上线了。结果过了一周收到老板的反馈，说他用最新款的折叠屏手机打开网页，侧边的导航栏直接占了半块展开的屏幕，主内容区被挤得只剩一条窄缝，连菜单图片都看不全。

你算啊，现在市面上的设备宽度从320px的老款安卓机，到折叠屏展开后2400px以上的超宽尺寸，还有各种带刘海、挖孔、灵动岛、侧边曲率的曲面屏，更别说还有用户开了系统级的字体放大，把默认字体调到最大号的那种——你写的固定行高的文本，直接溢出卡片边界，压到下面的按钮上。 别觉得这种用户少。我之前拉过合作平台的后台数据，开最大字体的用户占比居然有12%，大部分是眼神不好的中老年用户，人家本来就是为了看得清才调大字体，你页面排版直接乱成一团，人家转头就划走，半分停留都不会给。

那些藏在细节里的适配坑根本没人提前说

我见过太多团队的适配流程，就是写完页面扔到模拟器里，拉几个尺寸的窗口看一眼，觉得没错位就直接上线。 真的，这种操作迟早要踩坑。 比如用vw做适配的时候，很多人会忽略移动端浏览器的滚动条占的宽度，还有iOS端的橡皮筋效果，滑到页面顶部的时候，内容直接被悬浮的地址栏挡住，最下面的提交按钮被底部的工具栏遮掉一半。还有那个最磨人的1px边框问题，你在普通屏幕上看着是细得刚好的浅灰分割线，在高分屏上直接变粗成模糊的灰条，跟整个页面的质感完全不搭。 更别说输入框的适配，很多人写的时候没做滚动适配，在安卓端的自带浏览器里，点输入框弹起键盘的时候，页面根本不会自动把输入框滚到可视区域，用户输一半就看不到自己打了什么，这种体验谁受得了。

我之前带过的一个实习生，写适配的时候图省事，直接把所有图片都设成width:100%，结果在低分辨率的老安卓机上，加载高清图的时候直接把页面撑得能横向滚动，用户要左右滑才能看完整个页面，被我骂了半小时。真的，这种低级错误，只要你上线前多找几台不同尺寸的真机点一遍，根本不会犯，但大部分团队就是嫌麻烦，觉得模拟器测过就万事大吉。

真正落地的适配根本不需要写一堆冗余代码

很多人一提到适配，第一反应就是要堆十几个媒体查询，从320px到2560px每个断点都写一套样式，代码冗余到最后自己都改不动。 其实根本没必要。 你只要抓住几个核心的断点就行，比如针对小屏手机（1200px），这几个区间足够覆盖95%的真实用户了。 优先用流式布局代替固定宽度，别给容器写死px宽度，用百分比或者flex弹性布局，让元素自己根据屏幕宽度分配空间，比你写十套媒体查询都管用。还有所有可点击的元素尺寸别小于44px，不管是按钮还是文字链接，太小的话用户在手机上根本点不准，尤其是手大的男生，点三次都点不中，直接就放弃操作了。 哦对，字体别用固定的px值写死，用相对单位配合系统的字体缩放，哪怕用户把字体调到最大，文本也能自动适配容器宽度，不会出现溢出的情况。上线前的测试也别图省事，找几个用不同品牌、不同系统版本手机的真实用户，让他们走一遍完整的操作流程，哪里错位了、哪里点不动、哪里被挡住了，记下来改完再上线，比你事后加班改bug强一百倍。 说实话，现在很多团队做移动端适配，都是抱着“差不多就行”的心态，觉得反正大部分用户用的都是主流机型，出了问题再临时改。但你想想，你花了几万块投的流量，用户打开页面三秒钟排版就乱了，前面所有的推广投入直接打了水漂。真的，适配这事没什么高深的技术门槛，就是细心，多站在用户的角度想想，你自己用手机刷网页的时候最烦什么样的排版，你就别把自己的页面做成那样。