很多站点在桌面浏览器里看得很正常，一换到手机上就露馅：字小得要放大，按钮点不准，图片把版面撑出横向滚动条。移动端适配不是上线前做一次就完事的项目，而是站点运营里需要定期回头看的日常项。
为什么移动端适配值得单独立一项自查
两个原因。第一，多数站点的移动端访问占比已经不低，访客体验直接关系到停留时长和转化。第二，搜索引擎的抓取和渲染也越来越多地以移动端为基准，页面在移动环境下如果渲染异常、内容缺失或者必须横向滚动才能看全，蜘蛛拿到的页面质量自然会打折。
这里说的是改善体验和可抓取性，不等于做完适配就一定有更好的展现，它只是把该做的基础工作补齐。
第一层：viewport 与基础布局
先看最容易被忽略的一行代码。页面头部缺少 viewport 声明时，手机浏览器会按桌面宽度渲染再整体缩小，结果就是所有文字一起变小。
- 是否有 viewport 声明，常规写法是 width=device-width, initial-scale=1。
- 是否用 user-scalable=no 直接禁掉缩放，这会挡住需要放大阅读的用户，属于可访问性问题。
- 是否给容器写了固定像素宽度，比如 1200px，小屏上必然出现横向滚动。
- 是否用了弹性布局或栅格，而不是靠一堆 float 硬拼版面。
第二层：点击区域与文字可读性
- 可点击元素太小：导航、按钮、分页、关闭图标挤在一起，手指很容易点错。一般建议点击区域不小于 44×44 像素，相邻元素之间留出间距。
- 正文字号偏小：正文常见下限在 14 到 16 像素左右，辅助信息也不宜低于 12 像素。
- 行高过密：1.5 到 1.8 之间读起来比较舒服，太紧会让人看着累。
第三层：图片、表格与代码块
- 图片加 max-width:100% 并让高度自适应，避免撑破容器；条件允许时用 srcset 或按屏宽返回合适尺寸，别把桌面大图直接塞给手机。
- 宽表格放进可以横向滚动的容器里，而不是让整页跟着滚。
- 代码块和超长链接做溢出或换行处理，防止把布局顶出去。
第四层：弹窗、浮层与遮挡
首屏弹出全屏遮罩、自动播放的视频、常驻底部的悬浮条，这些在桌面端忍一忍还能接受，在手机上往往直接盖住主要内容。如果遮罩关不掉，或者关闭按钮小到点不中，访客大概率直接返回。运营侧要盯的是：浮层是否可以关闭、是否遮挡正文、是否影响了首屏内容的呈现。
第五层：表单与输入体验
- 输入框是否用了合适的 type，比如电话用 tel、邮箱用 email，让手机调出对应键盘。
- 输入框字号小于 16 像素时，部分系统在聚焦时会自动放大页面，跳一下很影响填写。
- 标签与输入框是否对齐，错误提示是否紧挨着对应的输入项。
怎么测：别只看自己手里那一台手机
- 用浏览器的设备模拟做初筛，再用真机复核，不同系统版本的表现会有差异。
- 横屏、小屏、大屏都过一遍，弱网环境下看看首屏能不能尽快出内容。
- 用带移动端 UA 的请求看一眼返回内容和状态码，确认没有因为 UA 不同而返回空页或错误页。
- 如果站点有独立的移动站，检查跳转关系、canonical 指向和适配声明是否一致，别出现桌面和手机互相指认对方的混乱情况。
服务器与资源层面的几个细节
- 不要按 UA 返回不同状态码，访客和蜘蛛看到的结果应当一致。
- 移动端首屏尽量少依赖大体积脚本，图片考虑 WebP 这类更省的格式。
- CDN 缓存策略要覆盖移动端资源，改版之后记得刷新。
一个可落地的巡检节奏
- 每月用真机抽查三到五个高频入口页，记录字号、点击、滚动情况。
- 每次改版或换模板后，重新过一遍上面五层检查。
- 把发现的问题记进一份清单，标注页面和日期，改完再回看一次。
移动端适配没有一劳永逸的状态，设备、系统、浏览器都在变。把它当成定期体检的项目，比上线前突击一次更靠谱。