语之溪
同一个业务功能在 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 端和移动端联调的目标，不是让两个页面长得一样，而是让同一个用户在不同终端执行相同业务时，接口契约、权限、状态和错误处理保持一致。只有分别验证真实请求和完整流程，才能确认终端差异没有改变业务结果。
