设计稿和上线页面不一致，UI验收怎样区分还原问题与数据问题
先在相同终端、视口、内容和状态下比较，再判断差异来自样式、资源、交互还是数据。截图只能证明某个时刻的外观；点击行为和业务结果必须单独验证。
阅读目录5 个章节
先建立可重复的比较条件
记录设计版本、页面版本、浏览器、窗口尺寸、系统缩放、语言和使用账号。准备一组可复用的测试记录，明确应处于加载完成、空数据还是错误状态。设计稿只有短名称而页面用了长公司名，不能只凭换行就断定开发没有还原。
同样，也不能用“真实数据较长”解释所有错位。设计范围若明确包含长标题和窄屏，运行页面就需要按既定规则换行，而不是截掉内容。比较条件的作用是让双方找到问题，不是降低可读性要求。
把差异分到正确的处理队列
- 视觉还原：层级、尺寸、颜色、间距和对齐与确认稿或共享规则不符。
- 资源问题：字体、图片、图标缺失或版本错误，导致另一种外观。
- 交互问题：点击、返回、焦点、加载反馈与约定不一致。
- 数据问题：字段、金额、单位、权限或状态结果不正确。
一处问题可能同时涉及几类。例如金额超长导致按钮被挤掉，要确认金额本身是否正确，再检查布局边界；不能只缩小数字把错误值藏住。记录应保留输入、操作、观察结果和预期依据。
字体与加载时机需要单独排查
同一段文字因字体替代而换行，不一定是容器宽度改错。开发可以检查字体请求是否失败、实际使用字体和加载前后布局。MDN字体加载API说明提供了观察字体加载状态的机制；等待字体处理完成有助于稳定截图，但不保证指定字体一定成功，也不能证明所有图片和业务数据已加载。
验收既要看稳定后的页面，也要看首次访问的过程。若字体或图片出现时导致操作位置明显变化，应按加载稳定性处理；不能只选择最终漂亮的截图。缓存存在与不存在的两次访问都值得核对。
用差异单代替“还差点感觉”
假设某条记录的英文标题遮住了操作按钮，差异单可写明页面、账号角色、语言、窗口尺寸、记录编号、操作步骤、截图与期望：标题完整换行，按钮保留且可点击。这样的说明能直接复现，远比“英文不好看”有效。说明性测试记录应去掉真实个人信息。
对于字体抗锯齿等平台差异，可先确认是否影响阅读与层次，再决定是否属于缺陷。不同系统不一定逐像素完全一致，但不能以此忽略丢字、遮挡、焦点不可见或关键按钮失效。
修正后如何复验
- 用原记录、原条件重现，确认问题已经消失，而不是测试数据换短了。
- 检查同类组件的另一个页面，避免局部补丁破坏共享样式。
- 换一个边界样本，例如空值、长值或无权限，检查修正仍成立。
- 实际完成点击、提交和返回，确认画面正常之外结果也正确。
- 记录修复版本和剩余事项，区分设计缺陷、待补资料与新增需求。
纯设计验收可确认稿件、状态和交接资料；实现验收才能判断页面是否运行正确。费用和修改轮次应按双方约定处理，不应从一张差异截图直接推定全部返工责任。
提交还原问题时，附上设计版本、实际记录和复现路径，便于沿原型交接约定判断缺失的是样式、状态还是功能。涉及旧软件还应核对需要保留的操作行为。UI设计服务的评审成果应落到可复验的问题记录，而非笼统的“看着不像”。