移动端适配实战踩坑笔记
2026-11-11 17:59:18
作者：
fawen
上周帮电商部擦屁股的618活动页，上线半小时收到200多条用户投诉——说按钮点不动，优惠券弹窗挡了半屏。
真的崩了。
我们当时按常规750px设计稿切的代码，所有元素都用rem做了换算，在测试机的iPhone13上跑的好好的，怎么一上线就炸？
哦对，忘了这次活动有三分之一的用户是用折叠屏手机打开的。
别上来就套通用适配模板
很多人刚接触移动端适配，第一反应就是去抄网上流传的十年前的rem模板——什么监听resize事件，动态改html的font-size，把设计稿除以100换算成rem单位。
说实话，这模板放在2016年还行，那时候安卓机尺寸乱，什么3.5寸到6寸都有，rem能统一缩放。现在呢？折叠屏展开之后宽度直接到800多px，你那套rem算出来的font-size直接翻了一倍，弹窗宽度本来是300px，直接撑到600px，在小屏手机上又缩的快看不见。
更坑的是，很多人抄模板的时候连注释都不看，里面写了“忽略横屏模式”，结果这次有用户把手机横过来抢优惠券，直接看到页面一半在屏幕外面，刷新都没用。
没人提前测横屏？也不是。测试同学手里的折叠屏都是合起来测的，谁会想到用户抢券的时候会把手机展开横着用。
电商商品页不同尺寸手机渲染对比图
90%的适配问题根本不是CSS的锅
我后来翻了投诉的截图，一半的问题是按钮被安卓的底部手势导航挡住了，还有三分之一是弹窗的圆角在低版本webview上显示成直角，剩下的才是缩放的问题。
这些事真的是前端的问题吗？
设计给的设计稿上，根本没标注底部安全区域的留白，只给了一张iPhone14的效果图，谁能想到安卓的手势条会占掉底部20px的高度？
产品提需求的时候，只说要在底部加个“立即抢购”的悬浮按钮，没说要避开手势返回的区域，用户往上滑返回的时候，直接就点到抢购按钮，跳去支付页了，能不投诉吗？
还有webview的兼容问题，运营要的渐变按钮，在微信旧版本的webview上直接显示成纯黑色，这难道是前端没加前缀？不对，加了也没用，那版本的webview根本不支持css3的渐变属性。
对吧，很多人一看到适配出问题，第一反应就是去改CSS代码，改了半天发现根上的问题是协作的时候没对齐规则。
移动端安全区域适配代码示例图
落地的时候别搞复杂方案
这次的坑填完之后，我们团队直接把之前那套祖传的rem模板删了。
现在所有新的活动页，直接用vw做单位。1px就是1vw，设计稿是750px的话，直接把px除以7.5换算成vw就行，根本不需要写js监听resize事件。
当然也不是直接全用vw。我们会给页面的最大宽度设成480px，超过这个宽度的话就居中显示，不会在折叠屏上把元素拉的太宽。最小宽度设成320px，老的小屏手机也能正常显示。
安全区域的适配更简单，直接给页面的底部元素加个padding-bottom: env(safe-area-inset-bottom)，不管是挖孔屏还是刘海屏还是手势导航，自动留出对应的空间，根本不需要写媒体查询去适配每个机型。
哦对，还有个偷懒的办法，所有需要点击的按钮，左右至少留16px的边距，上下高度至少48px的最小点击高度，符合移动端的点击规范，就不会出现“点不动”的问题。
不过话说回来，也不是所有场景都适合这个方案。如果是做复杂的企业级移动端应用，还是得用成熟的栅格系统，别为了省代码硬套简单方案，到时候改起来更麻烦。
昨天又碰到个同行跟我吐槽，说为了适配所有手机，写了500行适配代码，结果上线之后还是有用户说显示不对。
其实真没必要。
移动端适配从来不是要让所有设备上的显示完全一模一样，只要核心内容能看清，按钮能点，不出现挡屏、溢出的问题，就够了。
哦对，别忘了上线之前，找几个不同尺寸的手机测一遍，尤其是折叠屏和老机型，别等用户投诉了才去擦屁股。
免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。如有侵权请联系删除。
文章名称：
移动端适配实战踩坑笔记
文章链接：https://m.itcdj.com/news/732.html