最核心的验证点是新旧接口响应体是否一致，Postman通过Pre-request Script并发调用新旧服务并存入环境变量，再在Tests中深度比对；需处理空响应、JSON解析异常、动态字段剔除及状态码/结构语义一致性。
直接比对新旧响应体是否一致
迁移后最核心的验证点不是“能发出去”，而是“返回内容是否和原来一样”。Postman 本身不内置 diff 功能，但可以借助环境变量 + Pre-request Script 实现单次请求中并发调用新旧两个服务，并把结果存入变量供后续比对。
常见错误现象：pm.environment.set("old_response", {}) 后没做非空判断，导致后续 pm.environment.get("old_response") 取到空对象，断言直接失败；或未处理 old_response.json() 抛出的解析异常，脚本静默中断。
- 前置脚本里用
pm.sendRequest()调旧地址，必须加try/catch包裹response.json() - 新接口响应建议统一用
pm.test("status code is 200", () => { pm.response.to.have.status(200); });单独校验状态码，避免因旧服务超时导致误判 - 若响应含时间戳、ID 类动态字段，需在 Tests 里用正则或
JSON.parse()后删掉这些字段再做JSON.stringify()对比
用 Postman Runner 批量跑迁移前后集合
当接口数量超过 10 个，手动逐个比对不可行。应将旧版 Collection 和新版 Collection 分别导出为 collection_v1.json 和 collection_v2.json，再通过 Runner 指定不同环境（oldHost / newHost）批量执行。
使用场景：电商系统订单模块共 37 个接口，其中 5 个涉及金额计算，必须确保浮点精度、四舍五入逻辑完全一致。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- Runner 中勾选
Keep variable values，否则环境变量在每轮迭代中会被重置 - 新版 Collection 的每个请求 Tests 里，必须包含对
old_response和当前response的深度比对逻辑，不能只比 status - 导出报告时用
newman run collection_v2.json -e env_new.json --reporters html --reporter-html-export report.html，避免依赖 Postman GUI
绕过 CORS 或认证拦截导致的假失败
迁移后请求发不出去，未必是接口问题，很可能是前端调用链路中的中间层（如 Nginx、网关）拦截了 Origin 或缺少 Authorization 头。Postman 默认不带 Origin 头，也不会自动携带浏览器 Cookie，容易误判为“接口不可用”。
参数差异：pm.request.headers.add({key: "Origin", value: "https://example.com"}) 可模拟前端域名单，但仅用于调试；正式验证仍应关闭 CORS 检查或改用服务端直连方式。
- 先确认新域名是否已配置白名单——查 Nginx 的
add_header Access-Control-Allow-Origin配置项 - 若新服务启用 JWT，检查 Postman 中 Authorization 类型是否从
Bearer Token改为API Key，且 key 名是否匹配（如X-API-KeyvsAuthorization） - 用
curl -v -H "Origin: https://test.com" https://new-api.example.com/health直接验证，排除 Postman 自身干扰
注意 JSON 响应结构微小变动引发的兼容性断裂
开发常说“只是加了个字段”，但前端可能已用 response.data.items[0].price 硬编码取值。Postman 的 Tests 断言若只写 pm.expect(json.items).to.be.an('array')，会漏掉 items 被重命名为 productList 这类 breaking change。
性能影响：对大响应体（>1MB）做全量 JSON.parse + stringify 对比，会导致 Runner 执行变慢，单请求耗时从 200ms 升至 1.2s。
- 关键字段必须显式断言存在且类型正确，例如：
pm.expect(json).to.have.property('data').that.is.an('object'); - 用
pm.response.to.have.jsonBody({code: 0, msg: "success"});替代手动解析，更轻量 - 对列表类接口，加一条边界断言：
pm.expect(json.data.items).to.have.length.at.least(1);，防止空数组被当成成功
400 表示参数缺失，新版却返回 422；或者分页接口旧版 total 字段为字符串 "100"，新版改为数字 100 —— 这些都不会导致 Postman 显示红叉，但会让前端 JS 的 == 判断失效。 
