很多站点的移动端问题不是一天形成的，而是每次改版都往前挪一点：某个模块加了固定宽度，某个表格没做横向滚动，某个弹窗只在桌面端测试过。等访客用手机打开，页面能左右滑动、按钮点不中、内容被挡住，跳出率就上来了。移动端适配自查不需要多高深的技术，按顺序过一遍常见项，就能排掉大部分问题。
一、先看视口声明是否正确
视口声明是移动端适配的地基。如果缺失或者写错，浏览器会按桌面宽度渲染再整体缩小，文字看起来小得离谱，用户必须双指放大才能读。
- 检查 head 里是否有 viewport meta，常见写法是 width=device-width, initial-scale=1。
- 不要为了“看起来全”而写死一个很大或很小的宽度，也不建议长期使用 user-scalable=no，限制缩放对无障碍不友好。
- 模板改动、公共组件替换时，最容易顺手把这段删掉，改完记得回来看一眼。
二、横向溢出通常从哪来
移动端最直观的毛病就是页面能左右拖。逐项排查，通常会命中下面几类元素：
- 固定宽度的容器或图片，比如 width:1200px，直接超出屏幕。
- 宽表格铺开摆放，没有加外层滚动容器。
- 代码块、命令行示例、长 URL 不换行。
- 绝对定位或负边距元素跑出了可视区。
- 轮播、地图、嵌入的 iframe 没有做宽度自适应。
排查时可以先把视口切到 320px、375px、414px 这几个常见宽度，看是否出现横向滚动条。也可以临时给元素加一层描边，快速定位越界的那一个。
三、可点区域和字号
手指比鼠标粗得多。链接或按钮挨得太近、尺寸太小，就会出现“点了没反应”的体验，实际是点到了旁边。
- 主要按钮的点击区域建议不小于 44×44 像素。
- 正文默认字号不要低于 14px，行高留够，长段落才好读。
- 导航一级项之间留出间距，减少误触。
- 靠 hover 才能展开的菜单，在触屏上要有可点击的替代入口。
四、弹窗与悬浮层
移动端屏幕本来就小，一个占满屏幕的弹窗往往把正文彻底盖住。自查时重点看：弹窗是否有明确且足够大的关闭按钮；打开弹窗后背景是否还能滚动；首次进入就弹出的订阅框、客服浮窗有没有遮挡主要内容；悬浮客服按钮是否压住了底部的操作按钮或提示条。
五、移动端的加载表现
同一份代码，在手机和电脑上的表现可能差很远。网络更慢、CPU 更弱，首屏大图、自动播放视频、一次性渲染的长列表，都会让加载明显变慢。可以留意这几点：
- 首屏图片按实际显示尺寸输出，别用一张大图缩着放。
- 懒加载放在下文图片上，首屏关键资源不要延迟。
- 避免首屏同时发起大量第三方脚本请求。
六、一份可执行的自查流程
- 把页面依次在 320px、375px、414px、768px 几个宽度下看一遍，重点看是否横向滚动、是否内容重叠。
- 至少用一两台真机验证，模拟器和真机在手势、字体、弹窗行为上会有差别。
- 检查视口声明、正文字号、点击区域这三项基础设置。
- 走一遍完整流程：首页进栏目、打开详情、提交表单、翻页返回，看有没有卡住的地方。
- 把发现的问题按影响面和修复成本排个序，先修影响首屏和主流程的。
- 改完之后再走一遍同样的流程，确认没有引入新的溢出。
移动端适配不是一次性任务。模板、导航、公共组件一改，就可能影响全站手机端表现，改动后在窄屏下多看两眼，成本很低。
移动端自查的价值不在于追求某个评分，而是让访客在手机上能顺畅读完一页、顺利点完一个按钮。把上面这些项目做成一张检查表，每次改版后过一遍，很多问题就轮不到访客来替你发现。