一、接口联调概述：什么是接口联调、联调在项目中的位置、联调与单元测试的区别
说实话，做了这么多年全栈开发，我见过太多项目在联调阶段翻车了。今天咱们就来聊聊接口联调这件事。嗯，这可不是什么高深的理论，而是每个工程师都绕不开的实战环节。
1.1 什么是接口联调？
接口联调，说白了就是让前端和后端「对话」起来。前端发请求，后端给响应，两边数据能对得上，流程能跑通。
我习惯这么理解：
前端是个点菜员，后端是个厨师。
点菜员说「来一份宫保鸡丁」，厨师得能听懂，还得真做出来。
接口联调就是验证这个「点菜-做菜-上菜」的流程是否顺畅。
核心定义：接口联调是指将前后端模块按照接口文档进行对接，验证请求与响应的数据格式、业务流程、异常处理是否一致的过程。
我在项目中遇到过这样的情况：后端返回的字段名是 user_name，前端却按 username 来解析。这种小问题，联调时一测就暴露了。要是等到上线才发现，那可就尴尬了。
1.2 联调在项目中的位置
咱们先画一张图，看看联调在整个研发流程中处于什么位置。
从这张图能看出来，联调处于「并行开发」之后、「集成测试」之前。它是个承上启下的环节。为什么这么说？
- 承上：前后端各自开发完了，但各自为政。前端 mock 数据跑得欢，后端 Postman 测得爽。可一旦对接，问题就来了。
- 启下：联调通过后，才能交给测试团队做完整的集成测试。联调不过，测试根本没法测。
我的经验：联调最好在开发完成 80% 时就启动，不要等全部写完。先调通主流程，再补边缘 case。这样能提前暴露问题，避免后期大面积返工。
1.3 联调与单元测试的区别
这个问题，我经常被问到。很多新手容易把两者搞混。咱们用一张表来对比：
| 对比维度 | 单元测试 | 接口联调 |
|---|---|---|
| 测试对象 | 单个函数、方法、类 | 前后端之间的接口交互 |
| 测试范围 | 局部、模块内部 | 全局、跨模块、跨系统 |
| 执行者 | 开发人员（自己测自己的） | 前后端开发一起协作 |
| 依赖环境 | 可 mock，不依赖外部 | 需要真实环境或联调环境 |
| 验证重点 | 逻辑正确性、边界条件 | 数据格式、状态码、业务流程 |
| 发现问题 | 代码逻辑 bug | 接口不匹配、字段缺失、状态码错误 |
| 自动化程度 | 高（可 CI/CD 自动执行） | 低（需要人工参与） |
说白了，单元测试是「自己跟自己玩」，接口联调是「两个人一起玩」。你想想看，单元测试能保证你的加法函数 1+1=2 是对的，但它能保证前端传过来的参数是数字而不是字符串吗？不能。这就是联调要干的事。
我曾经踩过的坑：有一次，我负责的后端接口单元测试全部通过，覆盖率 95% 以上。结果联调时发现，前端传的日期格式是 "2024-01-01"，而我后端解析的是 "2024/01/01"。单元测试里我 mock 的数据全是正确格式，根本没暴露这个问题。从那以后，我养成了一个习惯：联调前先跟前端对一遍所有字段的格式和类型。
1.4 为什么联调这么重要？
我见过太多项目，开发阶段顺风顺水，一到联调就卡壳。原因无非这么几个：
- 接口文档不更新：文档写的是 v1，代码已经改到 v3 了。前端按文档调，后端按代码跑，对不上。
- 异常处理不一致：后端觉得「参数错误返回 400」，前端以为「参数错误返回 422」。结果前端收到 400 直接懵了。
- 数据类型不匹配：后端返回
id: 123（数字），前端期望id: "123"（字符串）。 - 业务流程有遗漏：登录成功后，后端返回了 token，但前端不知道 token 过期了该怎么刷新。
这些问题，单元测试一个都发现不了。只有联调才能把它们揪出来。
一句话总结：单元测试保证「代码是对的」，接口联调保证「对接是通的」。两者缺一不可。
1.5 联调的基本流程
我习惯把联调分成三步走：
- 第一步：准备阶段
- 确认接口文档是最新版本
- 搭建联调环境（测试服务器、数据库）
- 准备测试数据（各种正常和异常 case）
- 第二步：执行阶段
- 从前端页面触发请求，看后端能否正确响应
- 用 Postman 或 curl 模拟前端请求，验证后端接口
- 前后端一起盯着控制台，看请求和响应的具体内容
- 第三步：收尾阶段
- 记录联调中发现的问题
- 修复后重新验证
- 联调通过后，输出联调报告
嗯，这里要注意一点：联调不是一次性的。主流程调通后，还要覆盖异常场景。比如网络超时、参数非法、权限不足等等。这些 case 在单元测试里可能 mock 过了，但真实环境下表现可能完全不同。
好了，关于接口联调的基本概念就聊到这里。说白了，它就是让前后端「对上暗号」的过程。下一节咱们会深入讲联调的具体工具和实战技巧。