很多站点的移动端问题并不是“打不开”，而是悄悄少了一些东西：导航折叠后找不到入口，正文里的表格被裁掉一半，弹窗正好盖住主要内容。桌面端看不出毛病，手机上一看才发现访客和搜索引擎看到的是两套东西。移动端可用性自查不需要多复杂的工具，关键是固定几个检查位置，每次改版或上新模板时都过一遍。
为什么移动端值得单独查一遍
同一份内容，在窄屏上会经历更多变量：字号、行宽、折叠菜单、吸底元素、图片缩放。模板改一行样式，桌面端可能毫无变化，移动端却可能出现横向滚动或者按钮重叠。把移动端当作一次独立的验收环节，比事后靠访客反馈发现问题要省力得多。
五个必查位置
1. 视口设置与缩放行为
页面头部缺少 viewport 声明，或者写死了固定宽度，手机浏览器会按桌面宽度渲染再整体缩小，文字小到需要双指放大才能读。检查方法很简单：用手机打开页面，看正文是否需要放大；再看源码里 meta viewport 是否为 width=device-width, initial-scale=1。另外不建议顺手加上禁止缩放的属性，需要放大阅读的用户会很难受。
2. 移动端与桌面端的内容是否一致
为了“简化”移动端，有些模板会把正文后半段、参数表格、价格说明直接隐藏。用 display:none 藏起来的内容，移动端同样看不到；如果移动版和桌面版差异过大，等于给同一批页面准备了两份不同的答卷。自查方式：把同一篇文章的桌面版和移动版各截一张全文图，比对段落数量和关键信息有没有缺失。
3. 可点击元素够不够大、离得够不够远
导航、分页、按钮在桌面上排得整整齐齐，到手机上可能挤成一排很小的图标。手指点不准，就会误触到旁边的链接。经验上，主要交互元素的高度保持在 40 像素以上，彼此留出间距，误触会明显减少。
4. 弹窗、浮层和吸底组件有没有挡住主内容
订阅弹窗、App 下载引导、客服浮标，在桌面端只占一角，在窄屏上可能盖住半个屏幕。检查时注意三点：打开页面几秒后是否自动弹窗；弹窗能否一次关闭；关闭后是否反复出现。长期遮挡主内容的浮层，对访客和抓取都不友好。
5. 图片、表格和代码块会不会撑破布局
固定宽度的大图、宽表格、长代码行最容易在手机上造成横向滚动。常见处理方式是给图片加 max-width:100%，宽表格改成可横向滚动的容器，或者拆成卡片式布局。检查时可以故意把浏览器窗口拖窄，看整页有没有左右晃动。
一套十分钟能跑完的自查流程
- 准备好三台“设备”：一台真机、浏览器开发者工具的移动模拟、以及另一台不同系统的手机。
- 每条主要模板抽 1–2 个页面：首页、栏目页、内容页、搜索页、表单页。
- 逐页记录四个问题：是否需要放大才能读、是否有内容看不到、是否有元素点不准、是否出现横向滚动。
- 把问题按模板归类，能改一次影响全站的问题优先处理，避免逐页修补。
- 修改后用真机再滑一遍，并记录改动日期，方便下次对照。
几个容易忽略的误区
- 只看首页就收工。首页通常优化得最好，问题多出在内容页的表格、图集和长评论里。
- 以为用了响应式模板就万事大吉。框架只解决布局，内容里的固定宽度和内联样式照样会出问题。
- 用模拟器代替真机。模拟器看不到真实字号、真实网速和真实手指大小，重要模板还是用手机滑一遍。
- 把隐藏内容当成移动端精简。精简应该体现在排版上，而不是删掉关键信息。
移动端自查不是一次性任务，而是模板变更、栏目改版、上线新版页面之前固定要走的一步。留一份本地检查记录，比每次凭记忆回想更靠谱。
把结论落成清单
自查的价值不在于发现了多少问题，而在于形成一份可复用的清单：哪些模板要重点看，哪些标准是硬性的，改完之后由谁复验。把这份清单放进内容上线流程，移动端的问题就不会等到访客提意见才被看见。