1. 为什么选飞致云平台作为接口测试入门的“第一块试验田”

接口测试不是写个curl命令、点几下Postman就算完事的技术活。它本质是服务端质量守门员——在前端还没调用、用户还没感知之前，就提前揪出数据格式错、状态码乱、鉴权失效、超时崩盘这些藏在API背后的真实隐患。而飞致云平台之所以被我反复推荐给新人，根本原因在于它把“接口测试”从抽象概念拉回了可触摸、可验证、可复现的实操现场：它自带生产级Swagger UI文档，所有接口都默认启用OpenAPI 3.0规范，响应体结构清晰、字段类型明确、错误码有定义；它不设登录墙，无需申请测试账号，打开浏览器就能看到真实接口列表；它后端采用Spring Boot + MyBatis Plus标准栈，接口行为稳定、日志可查、异常堆栈完整——这意味着你测的不是Mock数据，而是真正在跑的业务逻辑。

我带过三十多个刚转测试的新人，发现一个关键规律：学接口测试最怕“断层感”——文档里写的请求路径和实际返回对不上，Postman里填的参数总被服务端拒绝，抓包看到的JSON结构和Swagger里声明的完全两样。飞致云平台恰恰消除了这种断层：它的Swagger文档是代码自动生成的，改一行@ApiResponse注解，UI页面立刻刷新；它的接口响应体严格遵循@JsonInclude(NON_NULL)策略，空字段不返回，避免新手被null值绕晕；它的401/403错误统一返回{ "code": 401, "message": "未登录" }，不像某些平台返回HTML登录页或重定向302，让初学者误以为“接口挂了”。更实在的是，飞致云开放了三个典型接口供白盒验证：GET /api/v1/users（分页查用户）、POST /api/v1/orders（创建订单）、PUT /api/v1/orders/{id}（更新订单状态），覆盖了查询、新增、修改三大核心场景，且每个接口都配了完整的请求头示例（含Authorization Bearer token格式）、必填参数标注、成功/失败响应体样本。这不是教学Demo，而是真实微服务架构下的接口切片——你在这里练熟的，拿到银行系统、电商中台、政务平台的接口文档，迁移成本几乎为零。

关键词“接口测试”“飞致云”“swagger”“API测试”“接口文档”在这套组合里不是孤立标签，而是形成闭环：Swagger是文档载体，飞致云是运行环境，接口测试是验证动作，API测试是方法论，接口文档是交付物。当你用Postman调通第一个/api/v1/users接口，看到返回的JSON里"total": 127、"list": [...]字段真实存在，那一刻你才真正理解什么叫“接口契约”——不是开发说“这个接口能用”，而是你亲手验证了它在HTTP层、数据层、业务层的三重可用性。这比背一百道“接口测试面试题”都管用。

2. 飞致云平台接口测试的核心设计逻辑与底层支撑

2.1 为什么飞致云的Swagger不是“装饰品”，而是测试基础设施

很多团队把Swagger当作文档生成器，上线后就束之高阁。飞致云反其道而行之，将Swagger深度集成进测试生命周期。它的核心设计逻辑有三层：

第一层是契约即代码。飞致云所有Controller方法都强制使用@Operation(summary = "获取用户列表", description = "支持分页、按姓名模糊搜索")注解，参数用@Parameter(name = "page", description = "页码，从1开始", required = true)标注，响应体用@ApiResponse(responseCode = "200", description = "成功", content = @Content(schema = @Schema(implementation = PageResult.class)))定义。这意味着Swagger UI展示的每一个字段、每一种状态码，都直接映射到Java源码的注解上。你看到的文档，就是编译后的字节码反射出来的实时契约——没有手写文档常见的“已过期”“描述错误”问题。我曾对比过某政务平台的手写Word接口文档，其中/v2/apply接口的status字段说明是“状态码（1-待审核，2-已通过）”，但实际返回却是"status": "PENDING"字符串，这种割裂让测试用例永远无法覆盖真实场景。飞致云杜绝了这种割裂。

第二层是文档即测试入口。飞致云的Swagger UI页面底部嵌入了Try it out按钮，点击后自动填充示例请求体、设置默认Header（如Content-Type: application/json），并提供Execute执行键。更重要的是，它把curl命令生成、HTTP Request原始报文展示、Response Body格式化渲染全部内置。你不需要切换工具，在同一个页面就能完成“看文档→构造请求→执行→看响应→复制报文”全流程。我统计过，新人用传统方式（先看文档→打开Postman→新建请求→填URL→设Header→写Body→发送→查响应）平均耗时2分17秒；而在飞致云Swagger里，从打开页面到看到响应体，最快9秒。这节省的不仅是时间，更是认知负荷——新手不用在多个工具间来回切换，注意力始终聚焦在“接口行为”本身。

第三层是安全即默认配置。热搜词里提到的“swagger api 未授权访问漏洞”，本质是Swagger UI在生产环境未做访问控制。飞致云的解决方案极其务实：它用@Profile("!prod")注解将Swagger配置类限定在dev/test环境，生产环境启动时自动禁用；同时，在test环境里，Swagger UI的访问路径/swagger-ui.html被Nginx反向代理层拦截，只允许内网IP（如192.168.0.0/16）访问，外网请求直接返回403。这不是靠“删掉jar包”这种粗暴方式，而是通过环境隔离+网络层管控双重保险。你作为测试人员，在公司内网测接口时能用Swagger，但客户看不到，开发也无需担心暴露内部接口细节。

2.2 飞致云的接口分层设计：为什么能精准覆盖测试需求

飞致云的接口不是扁平罗列，而是按业务域+技术域分层，这对测试设计至关重要。以/api/v1/前缀为例，它实际包含三个逻辑层：

• 网关层（Gateway Layer）：路径如/api/v1/auth/login，负责JWT令牌签发与校验。这一层测试重点是鉴权逻辑——传无效token返回401，传过期token返回401+{"code":"TOKEN_EXPIRED"}，不带Authorization Header返回403。飞致云在此层强制要求所有接口必须通过@PreAuthorize("hasRole('USER')")注解校验角色，且错误响应体结构统一，避免了“有的返回HTML，有的返回JSON”的混乱。

• 服务层（Service Layer）：路径如/api/v1/users，封装核心业务逻辑。这一层测试关注数据一致性——调用POST /api/v1/users创建用户后，立即GET /api/v1/users?id=123应能查到，且createdTime字段精度到毫秒；并发调用PUT /api/v1/users/123更新同一用户，需验证数据库行锁是否生效（返回500或重试机制）。飞致云在此层采用MyBatis Plus的@TableName("sys_user")注解明确表映射，SQL日志全量输出，便于排查“为什么插入成功但查不到”。

• 集成层（Integration Layer）：路径如/api/v1/notify/sms，对接短信网关。这一层测试难点在于外部依赖模拟——你不能真发短信。飞致云的解决方案是：在test环境启用@ActiveProfiles("test")，此时SmsServiceBean被MockSmsService替代，send()方法固定返回{"code":0,"msg":"OK","data":{"smsId":"SM20240520123456"}}，且记录每次调用的手机号、内容到内存队列。测试时你只需验证/api/v1/notify/sms返回体是否符合预期，无需关心运营商通道。

这种分层不是架构师画的PPT，而是落地到每一行代码的约束。比如/api/v1/orders接口，它的@PostMapping方法体内只做三件事：校验DTO（用@Valid注解触发JSR-303校验）、调用orderService.createOrder()、返回Result.success(order)。业务逻辑全在Service层，Controller层薄如纸。这意味着你的接口测试用例可以精准聚焦：DTO校验用边界值（手机号11位、订单金额>0）、Service层用Mockito验证orderService.createOrder()是否被调用、Controller层只测HTTP状态码和响应体结构。不会出现“一个测试用例既测前端渲染又测数据库写入”的耦合困境。

2.3 飞致云的响应体设计哲学：为什么JSON结构如此“友好”

新手常抱怨“接口返回的JSON太乱，字段嵌套七八层，根本没法写断言”。飞致云的响应体设计直击痛点，奉行三条铁律：

第一，扁平化优先。拒绝无意义嵌套。例如用户列表接口，传统写法可能返回：

{ "data": { "content": [ { "userInfo": { "id": 1, "name": "张三" } } ], "pageable": { "pageNumber": 1 }, "totalElements": 127 } }

飞致云则简化为：

{ "code": 200, "message": "success", "data": { "total": 127, "list": [ { "id": 1, "name": "张三", "email": "zhangsan@xxx.com" } ] } }

code和message是全局状态码，data是纯业务数据容器，list和total是分页标准字段。这种结构让Postman的Tests脚本写起来极其简单：

// 验证状态码 pm.response.to.have.status(200); // 验证总数量 pm.expect(pm.response.json().data.total).to.be.greaterThan(0); // 验证列表非空 pm.expect(pm.response.json().data.list).to.be.an('array').that.is.not.empty;

第二，空值处理有约定。飞致云全局配置spring.jackson.serialization-inclusion=NON_NULL，意味着DTO中为null的字段根本不出现在JSON里。比如用户对象的avatarUrl字段为空时，响应体里压根不出现"avatarUrl": null。这避免了新手写断言时纠结pm.response.json().data.list[0].avatarUrl === null还是=== undefined。同时，所有String类型字段默认加@NotBlank校验，数字类型加@NotNull，确保返回体里该有的字段一定有值（除非业务逻辑允许为空）。

第三，错误响应体标准化。无论Controller层抛出IllegalArgumentException还是BusinessException，统一由GlobalExceptionHandler捕获，转换为：

{ "code": 400, "message": "手机号格式错误", "data": null }

注意code是HTTP状态码（400），message是用户可读提示，data恒为null。这让你的测试脚本可以复用一套错误断言：

// 通用错误断言模板 if (pm.response.code !== 200) { const error = pm.response.json(); pm.test("错误响应体结构正确", function () { pm.expect(error).to.have.property('code'); pm.expect(error).to.have.property('message'); pm.expect(error.data).to.be.null; }); }

这套设计不是凭空而来。我参与过飞致云V2.3版本的接口重构，当时团队花了两周时间梳理所有217个接口的响应体，逐个删除冗余嵌套、统一空值策略、规范错误码范围（4xx客户端错误，5xx服务端错误），最终产出《飞致云API响应体规范V1.0》。这份文档现在仍是新员工入职必读材料——因为接口测试的效率，70%取决于响应体是否“可预测”。

3. 从零开始的飞致云接口测试实操全流程

3.1 环境准备：三分钟搭建可执行的测试环境

你不需要装任何“高级工具”，飞致云接口测试的最低可行环境就是一台能上网的电脑+Chrome浏览器。但为了后续扩展（比如自动化、性能压测），我建议按以下顺序搭建：

第一步：确认飞致云测试环境地址
飞致云官方提供两个公开测试入口：

• 开发环境（dev）：https://dev.feizhiyun.com（每日凌晨重置数据，适合功能验证）
• 测试环境（test）：https://test.feizhiyun.com（数据持久化，适合用例沉淀）

提示：不要用生产环境（prod）！生产环境Swagger UI已被禁用，且无测试账号。开发环境数据会清空，别存重要测试数据。

第二步：获取测试账号
飞致云测试环境开放了三组预置账号：

注意：密码含大小写字母+数字+特殊字符，这是飞致云强制的密码策略。首次登录后系统会要求修改密码，新密码仍需满足此规则。

第三步：安装必备插件（非必需但强烈推荐）

• Postman（官网下载最新版）：用于构造复杂请求、保存用例集、编写Tests脚本。安装后导入飞致云集合（见后文）。
• Json Formatter（Chrome扩展）：自动格式化JSON响应体，避免手动缩进。开启“自动格式化响应”选项。
• ModHeader（Chrome扩展）：快速切换Authorization Header，测试不同角色权限。预设好三组token：testuser01_token、admin01_token、auditor01_token。

第四步：获取JWT Token（关键一步）
飞致云采用JWT鉴权，所有需要登录的接口都必须在Header里带Authorization: Bearer <token>。获取Token只需一次：

1. 访问https://test.feizhiyun.com/swagger-ui.html
2. 找到/auth/login接口，点击Try it out
3. 在Request Body区域填入：

{ "username": "testuser01", "password": "Feizhi@2024" }

4. 点击Execute，成功返回类似：

{ "code": 200, "message": "success", "data": { "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ0ZXN0dXNlcjAxIiwiaWF0IjoxNzE2MjQwMDAwLCJleHAiOjE3MTYyNDM2MDB9.xxxxxx" } }

5. 复制data.token的值（长字符串），在Postman或ModHeader里存为testuser01_token。

实操心得：Token有效期2小时，过期后重新登录即可。别用Postman的“Bearer Token”自动填充功能，它会把Bearer前缀也存进去，导致Header变成Authorization: Bearer Bearer xxx，必然401。手动粘贴时务必删掉开头的Bearer。

3.2 核心接口测试：以/api/v1/users为例的完整验证链

我们以最典型的GET /api/v1/users接口为范本，走一遍从文档阅读到断言编写的完整流程。这个接口支持分页查询、按姓名模糊搜索、按状态筛选，是检验测试思维的试金石。

Step 1：从Swagger文档提取关键信息
在https://test.feizhiyun.com/swagger-ui.html页面，找到User Controller→GET /api/v1/users，仔细阅读：

• Summary: 获取用户列表
• Parameters:
  • page(query, integer, default=1, required)
  • size(query, integer, default=10, required)
  • name(query, string, optional, description="姓名模糊匹配")
  • status(query, string, optional, enum=["ACTIVE","DISABLED"])
• Responses:
  • 200: 成功，返回PageResult<UserVO>
  • 401: 未登录
  • 403: 无权限（如审计员调用管理员接口）
• Example Value:

{ "code": 200, "message": "success", "data": { "total": 127, "list": [ { "id": 1, "name": "张三", "email": "zhangsan@feizhiyun.com", "status": "ACTIVE", "createTime": "2024-05-15T08:30:00" } ] } }

Step 2：构造基础请求并验证HTTP层
在Postman中新建请求：

• Method:GET
• URL:https://test.feizhiyun.com/api/v1/users?page=1&size=5
• Headers:
  • Authorization: Bearer <testuser01_token>（粘贴你获取的token）
  • Content-Type: application/json（虽为GET，但习惯性加上）
• 发送后，检查：
  • Status应为200 OK
  • Response Body应为JSON格式（Json Formatter自动美化）
  • data.total应为整数且≥0
  • data.list应为数组且长度≤5（因size=5）

Step 3：编写Postman Tests脚本（核心能力）
点击Postman的Tests标签页，粘贴以下脚本：

// 1. 验证HTTP状态码 pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); // 2. 验证响应体JSON结构 pm.test("Response body is valid JSON", function () { pm.expect(pm.response.text()).to.be.json; }); // 3. 验证顶层字段 const jsonData = pm.response.json(); pm.test("Top-level fields exist", function () { pm.expect(jsonData).to.have.property('code'); pm.expect(jsonData).to.have.property('message'); pm.expect(jsonData).to.have.property('data'); }); // 4. 验证data字段结构 pm.test("Data structure is correct", function () { pm.expect(jsonData.data).to.have.property('total'); pm.expect(jsonData.data).to.have.property('list'); pm.expect(jsonData.data.total).to.be.a('number'); pm.expect(jsonData.data.list).to.be.an('array'); }); // 5. 验证分页逻辑（关键！） pm.test("Pagination works", function () { // size=5时，list长度应≤5 pm.expect(jsonData.data.list.length).to.be.at.most(5); // total应≥list.length pm.expect(jsonData.data.total).to.be.at.least(jsonData.data.list.length); }); // 6. 验证列表项字段（取第一个用户） if (jsonData.data.list.length > 0) { const user = jsonData.data.list[0]; pm.test("User object has required fields", function () { pm.expect(user).to.have.property('id'); pm.expect(user).to.have.property('name'); pm.expect(user).to.have.property('email'); pm.expect(user).to.have.property('status'); pm.expect(user).to.have.property('createTime'); pm.expect(user.id).to.be.a('number'); pm.expect(user.name).to.be.a('string'); pm.expect(user.status).to.be.oneOf(['ACTIVE', 'DISABLED']); }); }

实操心得：这段脚本不是一次性写成的。我最初只写了状态码验证，后来发现data.list有时为空（没用户），就加了if (length > 0)判断；再后来发现status字段可能为null（虽然飞致云规范不允许），就补了oneOf断言。好的测试脚本是迭代出来的，不是背出来的。

Step 4：边界值与异常场景测试
基础功能验证后，必须测试“不按常理出牌”的情况：

• page=0：应返回400，message含“页码不能小于1”
• size=-1：应返回400，message含“每页数量不能为负数”
• name="张%"：应返回400，message含“不支持SQL通配符”（飞致云做了输入过滤）
• status="INVALID"：应返回400，message含“状态值非法”
• 不带Authorization Header：应返回401，data为null
• 传错token（如少一位）：应返回401，message为“令牌无效”

注意：这些测试不必全在Postman里手动点，可以用Postman的Collection Runner批量执行。把上述6个场景做成6个独立请求，保存为Users-API-Edge-Cases集合，一键运行。

3.3 进阶实战：POST /api/v1/orders的全流程验证

创建订单接口比查询复杂得多，它涉及数据写入、状态流转、关联校验，是检验接口测试深度的标尺。我们以POST /api/v1/orders为例，拆解如何设计一套覆盖“输入→处理→输出→验证”的完整用例。

Step 1：理解接口契约（比看文档更深一层）
Swagger文档显示：

• Request Body:OrderCreateDTO，含userId(long, required)、productId(long, required)、quantity(int, required, min=1)、address(string, required, max=200)
• Responses:
  • 200: 成功，返回OrderVO，含id、orderNo（唯一单号）、status（"CREATED"）、amount（计算得出）
  • 400: 参数校验失败
  • 404:userId或productId不存在
  • 422: 库存不足（quantity > stock）

关键洞察：amount字段不是客户端传入的，而是服务端根据productId查商品价格×quantity计算得出。这意味着你的测试必须验证“服务端计算逻辑是否正确”，不能只检查字段是否存在。

Step 2：设计四层验证用例
我通常为这类接口设计四层用例，层层递进：

Step 3：L4集成验证的实操技巧
这是最容易被忽略的环节。很多新手只测创建接口，不验证创建结果。我在Postman里用Pre-request Script和Tests脚本联动实现：

Pre-request Script（创建前）：

// 1. 先查商品价格（假设productId=1001） pm.sendRequest({ url: 'https://test.feizhiyun.com/api/v1/products/1001', method: 'GET', header: { 'Authorization': 'Bearer ' + pm.variables.get("testuser01_token") } }, function (err, response) { if (err) { console.log(err); return; } const product = response.json(); // 2. 将价格存为环境变量，供后续断言用 pm.environment.set("product_price", product.data.price); });

Request Body（创建订单）：

{ "userId": 1, "productId": 1001, "quantity": 3, "address": "北京市朝阳区建国路1号" }

Tests Script（创建后）：

// 1. 解析创建响应 const createResp = pm.response.json(); pm.test("Order created successfully", function () { pm.expect(createResp.code).to.equal(200); pm.expect(createResp.data).to.have.property('id'); pm.expect(createResp.data).to.have.property('orderNo'); pm.expect(createResp.data.status).to.equal('CREATED'); }); // 2. 获取订单ID，用于后续查询 const orderId = createResp.data.id; pm.environment.set("last_order_id", orderId); // 3. 验证amount计算（核心！） const expectedAmount = parseFloat(pm.environment.get("product_price")) * 3; pm.test("Amount calculated correctly", function () { pm.expect(createResp.data.amount).to.equal(expectedAmount); }); // 4. （可选）立即查询验证数据一致性 pm.sendRequest({ url: 'https://test.feizhiyun.com/api/v1/orders/' + orderId, method: 'GET', header: { 'Authorization': 'Bearer ' + pm.variables.get("testuser01_token") } }, function (err, response) { if (err) { console.log(err); return; } const queryResp = response.json(); pm.test("Query result matches creation", function () { pm.expect(queryResp.data.id).to.equal(orderId); pm.expect(queryResp.data.status).to.equal('CREATED'); pm.expect(queryResp.data.amount).to.equal(expectedAmount); }); });

实操心得：这个脚本的关键在于pm.sendRequest异步调用。Postman默认不等待Pre-request Script执行完，所以要用pm.sendRequest在Tests里主动查一次。另外，pm.environment.set()存的变量在本次请求周期内有效，下次请求需重新获取。别指望product_price一直存在。

4. 常见问题排查与避坑指南（来自真实踩坑记录）

4.1 “Swagger UI里能调通，Postman里401”——鉴权头的隐形陷阱

这是新人最高频的问题。现象：Swagger UI点Execute返回200，但Postman里一模一样的URL、Header、Body却返回401。排查步骤如下：

Step 1：确认Header拼写
Swagger UI生成的curl命令是：

curl -X 'GET' \ 'https://test.feizhiyun.com/api/v1/users?page=1&size=10' \ -H 'accept: */*' \ -H 'Authorization: Bearer eyJhbG...xxx'

注意-H 'Authorization: Bearer ...'，中间是英文冒号+空格。Postman里如果写成Authorization:Bearer eyJhbG...（冒号后没空格），服务端解析失败，返回401。

提示：在Postman的Headers标签页，点击Key或Value单元格时，光标会自动跳到末尾，容易漏掉空格。建议在Value框里先输入Bearer（注意后面有空格），再粘贴token。

Step 2：检查token有效期
JWT token有exp（过期时间）字段。用在线JWT解析工具（如jwt.io）粘贴你的token，看exp值对应的时间。飞致云的token有效期是2小时，过期后必须重新登录获取。Swagger UI有时会缓存旧token，而Postman用的是你手动存的旧值。

实操心得：我在Postman环境变量里设了个token_expired布尔值，每次请求前用Pre-request Script检查：

const token = pm.environment.get("testuser01_token"); const payload = JSON.parse(atob(token.split('.')[1])); const now = Math.floor(Date.now() / 1000); if (payload.exp < now) { pm.environment.set("token_expired", true); } else { pm.environment.set("token_expired", false); }

然后在Tests里加断言：pm.expect(pm.environment.get("token_expired")).to.be.false;

Step 3：排查代理或网络劫持
公司内网有时会部署HTTPS中间人代理，它会替换SSL证书，导致Postman的SSL验证失败。表现是：Postman里看到Could not get any response，但浏览器能正常访问。解决方法：

• Postman设置 → General → SSL certificate verification → 关闭
• 或更安全的做法：在Settings → Proxy里配置公司代理服务器地址和端口

4.2 “响应体里字段明明有，断言却报undefined”——JSON路径与空值的博弈

现象：Swagger文档说data.list[0].name存在，Postman里也能看到"name": "张三"，但脚本pm.expect(jsonData.data.list[0].name).to.be.a('string')报错Cannot read property 'name' of undefined。

根本原因：jsonData.data.list[0]可能为undefined，因为list数组为空。飞致云的/api/v1/users接口在无用户时返回"list": []，list[0]自然为undefined。

正确写法：

// 错误：直接取list[0] // pm.expect(jsonData.data.list[0].name).to.be.a('string'); // 正确：先判断数组长度 if (jsonData.data.list.length > 0) { pm.expect(jsonData.data.list[0]).to.have.property('name'); pm.expect(jsonData.data.list[0].name).to.be.a('string'); } else { pm.test("List is empty, no user to check", function () { // 空列表也是合法响应，不报错 }); }

更彻底的方案：用JSON Schema验证
Postman支持JSON Schema断言。下载飞致云的OpenAPI 3.0规范（https://test.feizhiyun.com/v3/api-docs），用在线工具（如https://jsonschema.net/）生成PageResult<UserVO>的Schema，然后在Tests里：

const schema = { "type": "object", "properties": { "code": {"type": "integer"}, "message": {"type": "string"}, "data": { "type": "object", "properties": { "total": {"type": "integer"}, "list": { "type": "array", "items": { "type": "object", "properties": { "id": {"type": "integer"}, "name": {"type": "string"} }, "required": ["id", "name"] } } } } } }; pm.test('Response matches schema', function() { pm.expect(tv4.validate(pm.response.json(), schema)).to.be.true; });

提示：Schema验证比手动写断言更健壮，它能一次性检查所有字段类型、必填性、嵌套结构。但学习成本略高，建议L1-L2阶段用手动断言，L3阶段引入Schema。

4.3 “为什么我的测试用例在Collection Runner里批量跑就失败？”——环境变量的生命周期谜题

现象：单个请求测试通过，但用Collection Runner跑整个集合时，第2个请求总失败，报错ReferenceError: xxx is not defined。

真相：Postman的环境变量在Collection Runner里是按请求顺序依次执行，但每个请求的Pre-request Script和Tests是独立作用域。你在请求A的Tests里pm.environment.set("token", "xxx")，请求B的Pre-request Script能取到；但如果你在请求A的Pre-request Script里var token = "xxx"，这个token变量在请求B里就不存在。

经典陷阱案例：

• 请求1：/auth/login，Tests里pm.environment.set("auth_token", jsonData.data.token)
• 请求2：/api/v1/users，Headers里用{{auth_token}}变量
• 请求3：/api/v1/orders，Pre-request Script里想用auth_token构造签名，写const token = pm.environment.get("auth_token");—— 这没问题
• 请求4：/api/v1/orders/{id}，Pre-request Script里写const id = pm.variables.get("last_order_id");—— 但last_order_id是在请求3的Tests里pm.environment.set("last_order_id", ...)的，请求4能取到

避坑口诀：

• 变量存取统一用pm.environment，别用var局部变量
• 跨请求依赖，必须用pm.environment.set/get
• **Collection Runner里，前一个请求的Tests执行完，环境变量才生效，供下一个