很多站点的移動端問题不是一天形成的，而是每次改版都往前挪一点：某個模块加了固定宽度，某個表格没做横向滚動，某個彈窗只在桌面端測試過。等訪客用手机打開，頁面能左右滑動、按钮点不中、内容被挡住，跳出率就上来了。移動端适配自查不需要多高深的技術，按顺序過一遍常见項，就能排掉大部分問题。
一、先看视口声明是否正确
视口声明是移動端适配的地基。如果缺失或者寫错，浏览器會按桌面宽度渲染再整体缩小，文字看起来小得离谱，用戶必须双指放大才能讀。
- 检查 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 几個宽度下看一遍，重点看是否横向滚動、是否内容重叠。
- 至少用一两台真机驗證，模拟器和真机在手势、字体、彈窗行為上會有差別。
- 检查视口声明、正文字号、点击区域這三項基础設定。
- 走一遍完整流程：首頁進栏目、打開詳情、提交表單、翻頁返回，看有没有卡住的地方。
- 把發現的問题按影响面和修复成本排個序，先修影响首屏和主流程的。
- 改完之後再走一遍同样的流程，確認没有引入新的溢出。
移動端适配不是一次性任務。模板、導航、公共组件一改，就可能影响全站手机端表現，改動後在窄屏下多看两眼，成本很低。
移動端自查的價值不在于追求某個评分，而是让訪客在手机上能顺畅讀完一頁、顺利点完一個按钮。把上面這些項目做成一張检查表，每次改版後過一遍，很多問题就轮不到訪客来替你發現。