移动端适配开始前需要哪些网站资料：一份可执行清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6d1804ad1836.html
📄
移动端适配开始前需要哪些网站资料：一份可执行清单
移动端适配开始前，需要准备的网站资料包括：当前移动端流量与访问数据、现有页面的HTML与CSS结构、视口设置、响应式断点、图片与媒体资源规格、字体与交互组件、以及主要模板的截图或URL清单。这些资料决定了适配从哪一层改起、改动范围多大、以及如何验证结果，而不是直接开始改样式。
先查访问数据：确认移动端是否真的需要优先处理
要查的是：网站分析工具中移动端（手机、平板）的会话占比、跳出率、平均停留时长、转化路径完成率，以及移动端与桌面端在相同页面上的表现差异。
怎么查：在分析后台按设备类别筛选，导出近30天或近90天的页面级数据，重点看首页、栏目页、详情页、表单页和结算页。若没有分析工具，可先用服务器访问日志按User-Agent粗略统计。
结果说明什么：如果移动端会话占比明显高于桌面端，但跳出率也更高、停留更短，说明适配优先级高，且问题可能集中在布局、加载速度或交互上。如果移动端占比很低，适配仍要做，但可以按页面类型分批推进，不必一次性全站重写。
再查页面结构与视口：确定改的是模板还是单页
要查的是：页面是否设置了视口元标签、是否存在固定宽度容器、是否使用了响应式栅格、主要断点分别设在哪些宽度。
怎么查：在浏览器中打开目标页面，查看源代码中的<meta name="viewport">；用开发者工具的设备模拟切换不同宽度，观察是否出现横向滚动条、内容溢出、文字过小或按钮难以点击。再抽查三到五个典型模板，而不是只看首页。
结果说明什么：如果视口缺失或写死为固定宽度，适配需要从页面头部和基础布局改起，影响全站模板。如果视口正常但个别页面溢出，问题更可能出在该页的局部组件或内联样式，可以单页修复。若断点混乱、同一组件在不同页面表现不一致，应先统一断点规范再改样式。
整理资源清单：图片、字体与交互组件
要查的是：图片是否按移动端尺寸提供、是否使用懒加载、字体文件大小与加载方式、按钮和导航在小屏上的可点区域、弹窗与下拉菜单的触发方式。
怎么查：列出主要页面用到的图片格式与显示尺寸，对比移动端实际渲染宽度；检查字体是否阻塞首屏；在设备模拟中测试导航展开、表单输入、轮播滑动和弹窗关闭。
结果说明什么：图片远大于实际显示尺寸，说明需要生成移动端尺寸或改用现代格式。字体过大或阻塞渲染，说明要调整加载策略。交互组件在小屏上难以操作，说明适配不只是CSS宽度问题，还涉及触控目标和事件处理。
建立检查项与验证方法：改完怎么判断有效
可执行步骤：
- 列出需要适配的页面清单，按模板分组，标注每组的代表URL。
- 为每组记录当前移动端表现：是否有横向滚动、首屏主要内容是否可见、表单是否可完成。
- 设定断点与布局规则，先改一组模板，再在相同设备模拟条件下复测。
- 用真实手机抽查，而不仅依赖模拟器；模拟器与真机在字体渲染、触控和性能上可能有差异。
- 对比改动前后的移动端跳出率、停留时长和转化完成率，判断适配是否带来实际改善。
适用条件与判断结果：如果页面以内容阅读为主，优先保证文字可读、图片不溢出、导航可展开即可；如果页面以表单或交易为主，必须优先保证输入框、按钮和错误提示在小屏上可用。验证时若只有样式变化而没有行为改善，说明适配还停留在表面，需要回到交互与加载层继续排查。
下一步
先按上述清单收集资料，再从移动端访问占比最高、问题最集中的一组模板开始改，改完用真机复测并对比改动前后的移动端行为数据，再决定是否扩展到全站。
