移动端优化_怎样记录变更与复盘：交接验收时能查什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9026a17c8637.html
📄
移动端优化_怎样记录变更与复盘：交接验收时能查什么
移动端优化的变更记录与复盘，核心是让接手的人不看聊天记录也能判断“改了什么、为什么改、结果怎样”。做法是把每次改动写成一条可核对的记录：改动前的问题、改动内容、验证方式、结果与结论；交接或验收时，逐条对照页面现状和可查数据，而不是听口头描述。
先明确记录的对象是页面行为，不是操作动作
“把字号调大了”是操作动作，“360px 宽度下正文需要横向滑动，改为 16px 后单行可读”才是可复盘的记录。移动端优化的对象通常包括：视口设置、点击目标尺寸、字体与行高、图片与脚本体积、首屏内容顺序、弹窗与遮挡、横向溢出。记录时写清页面、设备宽度、改动前后表现，才具备验收价值。
抓取、索引与排名是不同环节。移动端改动可能影响的是页面可用性与内容呈现，是否被收录、是否获得排名是另外的判断，不要在同一条记录里混为一谈。
一条变更记录应包含的字段
建议用固定模板，字段少而稳定，便于交接时快速扫读：
- 标识：日期、页面路径、改动负责人。
- 问题：改动前可观察到的现象，例如“375px 下按钮间距小于可点范围”。
- 改动：具体到属性或文件，例如“将 <h2> 下方按钮外边距由 4px 调整为 12px”。
- 验证方式：用什么宽度、什么工具、看哪一项。
- 结果：改后现象，附截图或数据来源。
- 结论与遗留：是否达成目标，是否有未处理项。
技术示例中提到的标签名要写成转义形式，避免被当成页面结构解析。记录里引用代码时，直接写属性名和值即可。
按观察、判断、处理、复查四步执行
观察：在至少两个宽度下查看同一页面，例如 360px 与 414px，记录溢出、遮挡、点击目标过小等具体现象。可用浏览器开发者工具的设备模拟，但模拟不等于真机，关键结论应在真机复核。
判断：区分“可能原因”与“已经定位的原因”。出现横向滚动，可能是某个固定宽度元素、可能是长英文单词、也可能是图片未设最大宽度；在未逐项排除前，只能记为疑似原因。
处理：一次只改一类问题，改动范围写清。若同时调整字号与图片，后续无法判断是哪一项带来变化。
复查：用与观察阶段相同的宽度和页面重新检查，确认原现象消失且未引入新问题，例如换行位置变化、按钮被遮挡。
交接与验收时的检查项
验收不是重做一遍优化，而是核对记录与现状是否一致：
- 打开记录中列出的页面，按记录的宽度逐项复现，看现象是否与“结果”一致。
- 检查是否有记录缺失的改动，例如页面已改但记录未更新。
- 确认遗留项是否写明处理状态，而不是空白。
- 抽查一条记录，看“验证方式”能否被他人独立执行。
若记录中写的是“已优化移动端体验”，无法验收；写成“360px 下正文无横向滚动，点击目标不小于 44px”，才可以逐项核对。这里的 44px 是常见参考值，不是唯一标准，具体以项目约定为准。
复盘要产出可执行的结论
复盘不是重述改动清单，而是回答三个问题：改动是否解决了原问题；是否带来新的问题；下次遇到同类现象应先查什么。把结论写成短句，例如“横向溢出优先查固定宽度元素与未压缩图片”，下次交接时可直接复用。
下一步：挑一条最近的移动端改动，按上述字段补成完整记录，并请一位未参与改动的人按记录独立复现一次。若对方能复现出相同结果，记录就算合格；若不能，缺的字段就是需要补的地方。
