宁语之溪 - 移动端
type: channel
link: https://nyzx.de/tag/mobile/
items: PC 端和移动端联调时，我会检查什么
items: PC 端和移动端验证时，我会关注哪些问题

PC 端和移动端联调时，我会检查什么
type: item
date: 2025-11-29T17:14:00+08:00
description: 同一个业务功能在 PC 端和移动端可能使用不同页面布局，但它们背后通常要遵循相同的业务状态、权限和数据规则。联调时，我关注的不只是两个页面能不能发出请求，还要确认请求参数、认证方式、响应结构、错误处理和状态更新是否一致。页面适配属于终端验证的一部分，而这篇更关注前端与接口之间怎样对齐。先确认接口契约开始联调前，我会先把接口的基本约定列清楚：请求方法和经过脱敏的路径；请求头和认证要求；查询参数或请求体结构；必填、可选和默认字段；字段类型、长度和取值范围；正常响应和错误响应格式；是否支持重复提交或幂等处理。页面操作 -> 请求参数 -> 接口校验 -> 业务处理 -> 响应数据 -> 页面状态更新这是一条通用联调链路，不对应某个内部系统的真实接口。PC 端和移动端请求要逐项对照两个终端即使调用同一个接口，也可能因为组件、序列化方式或交互流程不同，传出不同参数。我会对照检查：字段名和大小写是否一致；空字符串、null 和未传字段是否被区别处理；数字、布尔值和日期是否使用相同格式；分页参数是否从同一个起始值开始；上传文件的字段名和类型是否一致；列表筛选与详情查询是否使用同一业务标识。不能因为 PC 端已经联调通过，就默认移动端一定使用相同请求。需要分别观察实际请求和响应。认证与权限不能只看页面入口PC 端和移动端可能使用不同的登录页面或令牌存储方式，但服务端权限规则应该保持一致。联调时可以确认：登录状态 -> 请求携带认证信息 -> 服务端识别用户 -> 角色与数据范围校验 -> 返回允许访问的数据需要特别检查登录失效、权限不足和角色变化后的表现。前端隐藏按钮不能代替服务端校验，移动端也不能因为入口不同而绕过数据范围。公开文章不写真实账号、Token、权限码和内部认证配置。状态变化要在两个终端同步业务表单和审批类功能经常涉及草稿、提交、待处理、退回和完成等状态。一个终端完成操作后，另一个终端重新进入页面时，应该能够获得最新状态。我会检查：提交成功后列表和详情是否刷新；返回上一页时是否仍显示旧数据；移动端缓存是否影响最新状态；待办数量和业务记录状态是否同步；已处理记录是否还能重复操作；接口失败时页面是否错误地更新为成功。具体状态名称和流程节点属于内部业务，文章只使用抽象表达。错误响应也需要统一理解正常请求容易联调，真正容易产生差异的是异常情况。PC 端可能展示接口返回的消息，移动端可能只显示一个统一提示，导致用户不知道下一步怎么处理。下面是通用错误响应示例，不来自真实项目：{ "code": "INVALID_STATE", "message": "The record cannot be submitted in its current state", "data": null }联调时需要确认：HTTP 状态码和业务错误码如何配合；两个终端是否都能识别错误结构；错误后是否保留用户已经填写的内容；是否允许重试；重试会不会造成重复提交；提示信息是否暴露内部异常或敏感数据。弱网和重复操作移动端更容易遇到网络切换和请求延迟，但 PC 端也可能出现重复点击。联调时不能默认一次点击只会产生一次请求。用户提交 -> 按钮进入加载状态 -> 请求超时或成功 -> 服务端幂等判断 -> 页面根据最终结果更新可以检查按钮是否及时禁用、超时后是否允许安全重试、服务端是否能够识别重复请求。具体幂等实现要根据业务规则和现有架构确定，不能从通用示例直接推断内部方案。文件、日期和富文本更容易出现终端差异普通文本字段通常比较直接，文件上传、日期时间、图片和富文本更容易受到终端影响。我会关注：移动端选择的文件类型和大小；上传过程是否有进度和失败提示；日期是否受到本地时区影响；PC 端与移动端是否使用相同格式提交；图片方向、压缩和预览是否影响实际文件；富文本内容在不同终端是否被重复转义。这些都是通用联调检查点，不代表内部项目已经发生过相应故障。联调记录要能够复现发现问题时，只写“移动端接口不对”很难继续定位。我会记录终端、页面入口、操作步骤、请求参数、响应结果、预期结果和复测状态。终端与环境 -> 操作步骤 -> 脱敏请求 -> 脱敏响应 -> 页面实际表现 -> 预期表现 -> 修复后复测敏感请求头、Token、用户标识和业务数据必须在记录和对外沟通前脱敏。PC 端和移动端联调的目标，不是让两个页面长得一样，而是让同一个用户在不同终端执行相同业务时，接口契约、权限、状态和错误处理保持一致。只有分别验证真实请求和完整流程，才能确认终端差异没有改变业务结果。

PC 端和移动端验证时，我会关注哪些问题
type: item
date: 2025-11-29T16:41:00+08:00
description: 同一个业务页面，在 PC 端和移动端上可能表现得完全不同。屏幕宽度、输入方式、网络环境和浏览器行为都会影响用户最终看到的结果。因此，移动端验证不只是把浏览器窗口缩窄，再看页面有没有溢出。它需要回到业务流程，确认用户能不能找到入口、完成操作，并在异常情况下得到清晰反馈。先看布局是否还能表达业务PC 端通常有更大的横向空间，可以同时展示菜单、筛选条件、表格和操作按钮。移动端空间有限，同样的内容可能需要折叠、换行、横向滚动或改成卡片展示。同一业务数据 -> 不同屏幕尺寸 -> 布局适配 -> 信息层级调整 -> 操作入口验证适配时不能只关注元素是否挤在一起，还要看重要信息是否仍然突出，操作按钮是否容易找到，长文本和错误提示是否会遮挡其他内容。触控操作和鼠标操作不同PC 端常见的悬停、右键和精确点击，在移动端不一定成立。按钮太小、间距太近、弹窗关闭区域不明显，都会让操作变得困难。移动端验证时，可以重点检查：点击区域是否足够大；表单输入是否会被键盘遮挡；下拉、日期和文件选择是否能正常使用；弹窗和抽屉是否能关闭；提交按钮在滚动后是否仍然容易找到。这些是通用移动端交互检查项，不对应某个内部页面或组件。数据和权限不能因终端变化PC 端和移动端可以使用不同的布局，但不应该因为终端不同而出现不一致的数据和权限。用户在手机上看到的业务范围，仍然应该遵循账号、角色、组织和记录状态的规则。同一用户 -> 登录认证 -> 权限判断 -> 数据范围过滤 -> 终端适配展示页面端可以根据尺寸隐藏或折叠部分内容，但权限判断不能只放在前端。接口仍然需要验证用户是否有权访问和操作数据。网络条件会改变体验移动端更容易遇到网络切换、延迟、弱网和请求中断。页面不能默认所有请求都会快速成功。测试时可以关注：加载状态是否明确；重复点击是否会产生重复提交；请求失败后是否可以重试；页面返回或刷新后状态是否丢失；文件上传和下载是否有进度或错误提示。这些检查和 PC 端也有关，但移动网络下更容易暴露问题。公开文章不涉及内部网络和服务器配置。表单和审批流程要完整走一遍业务系统中的表单、审批和工作台在不同终端上都需要验证。不能只打开首页确认样式正常，还要完成从创建、填写、提交到查看结果的流程。打开入口 -> 填写表单 -> 提交请求 -> 查看状态 -> 进入待办或结果 -> 返回并再次确认如果某个页面在移动端无法显示完整字段，或者审批状态更新后入口没有同步，用户就可能无法完成业务。验证时应该同时看页面布局、接口返回、权限和业务状态。浏览器和终端组合PC 端和移动端并不是两种固定设备。不同浏览器、系统版本、屏幕比例和输入方式都可能产生差异。实际测试不一定要覆盖所有设备，但应该根据用户主要使用场景选择代表性组合，并记录浏览器、系统、屏幕尺寸和网络条件。这样出现问题时，才能判断是业务逻辑、样式适配还是环境差异。验证结果要能复现一个好的终端问题记录，不只是写“手机上显示异常”。还应该包含：使用的终端、页面入口、操作步骤、实际结果和预期结果。环境信息 -> 复现步骤 -> 实际结果 -> 预期结果 -> 影响范围 -> 修复后复测这样，开发和测试才能围绕同一个问题沟通，修复后也能确认是否真正解决。PC 端和移动端验证的重点，不是追求每个像素都完全一样，而是确保用户在不同终端上都能理解页面、完成业务操作，并且受到一致的权限和数据规则约束。