从最头疼的环境切换开始说吧。我刚用Postman做接口调试的时候基本靠硬编码测试环境的地址、登录接口返回的token、分页参数里的用户ID全都写死在请求里。结果每次开发说“服务切到测试环境了”我就得把所有请求里的IP改一遍token过期了就得重新跑一遍登录接口再手动复制几十个字符到每个请求头里。那段时间做接口测试的效率基本被复制粘贴磨掉了大半。后来把Postman的变量体系彻底用起来才算真正解放了。Postman的变量本质上就是一组可以反复引用的命名占位符请求发出前会自动替换成具体值。本文从实际使用角度把全局变量、环境变量、局部变量、数据变量这几种类型以及变量优先级、动态变量、踩坑经验都串一遍适合刚接触Postman的测试新手也适合已经在用但偶尔被变量问题卡住的老手。1. 从硬编码到参数化为什么说变量是Postman的灵魂功能很多人把Postman当成一个“可以保存请求的工具”这其实太屈才了。Postman真正拉开差距的地方是它的变量体系和脚本引擎。变量让请求从“写死的文本”变成“可复用的模板”这是接口调试和自动化测试之间最重要的一座桥。1.1 硬编码带来的三个真实痛点先还原一下没使用变量时的几个典型场景。第一环境切换成本高。开发环境是http://192.168.1.100:8080测试环境是http://test-api.company.com生产环境是https://api.company.com。你可能会说你CtrlH全文替换就行但Postman里的每个请求、每个请求头、每个请求体都可能散落着环境地址。一旦环境切换改错一个地方接口就报404或者连接被拒。第二登录态难以复用。几乎所有业务接口都需要在请求头里带Authorization或token。你每跑一个接口都要先执行登录接口然后把返回的token复制出来粘贴到目标接口里。token过期后这个流程从头再来一次。第三数据重复维护。比如接口里有个动态的订单号、随机用户名或者需要在多个接口间传递同一个ID。你靠手工复制粘贴粘错了就是一次无效的调试。1.2 变量的原理发送请求前的模板替换Postman中变量的工作方式并不复杂。你可以在URL、请求头、请求体、脚本、断言里写{{变量名}}Postman在真实发送HTTP请求之前会做一次文本层的模板替换把这些占位符替换成当前作用域下解析到的实际值。我的理解是Postman本质上分成了两层编辑层和运行时层。你在界面上看到的是带{{}}的模板但真正发出去的请求是替换后的结果。这种方式的好处是显而易见的——你维护的是一组变量值而不是复制粘贴的碎片化文本。比如URL写成https://{{baseUrl}}/api/users不管baseUrl怎么变请求本身不需要动。这类变量解析的过程在Pre-request Script阶段就已经开始了所以你在脚本里给变量赋了值当前请求就能直接用上。1.3 变量体系总览五种作用域Postman的变量体系总共有五种作用域容易入门时记混变量类型存放位置生命周期典型场景全局变量Environment面板的Globals一直存在所有集合、所有请求可见跨集合共享的公共配置集合变量集合根目录的Variables标签页跟随集合存在集合内统一的基础信息环境变量某个具体环境内切换到该环境时生效不同环境的地址、账号数据变量Collection Runner导入的CSV/JSON每次迭代读取一行数据驱动测试局部变量脚本运行时临时存储当前请求执行周期内计算中间值、临时标记这五种变量同时存在时会有一个优先级顺序后面专门讲。现在先记住局部最高、环境次之、全局兜底就够了。2. 四种常用变量类型作用域划分与优先级规则这一节把最常用的四类变量——全局、环境、局部、数据——拆开来聊聊每个都给出推荐使用习惯和反面案例。2.1 全局变量适合公共配置不适合敏感信息全局变量的特点是没有环境限制在任何请求里都能访问。我一般用它来存那些所有环境都一样的数据比如App名称、版本号、公共的请求来源标识。反面案例是有人把密码、密钥放到全局变量里图省事。但全局变量在导出整个环境文件时很容易被顺带带走如果分享给同事或者传到仓库就相当于把敏感信息公布出去了。我的建议是全局变量只放非敏感的公共值比如默认分页大小、重试次数。创建路径点击左侧Environments切到Globals标签页写Key-Value。注意Globals的初始值Initial Value和当前值Current Value分离初始值会跟着分享走当前值只在你本地生效。2.2 环境变量环境切换的真正主角环境变量是Postman变量体系里最实用、最值得掌握的一个。你可以在Environments面板里建立多套环境每套环境里的baseUrl、username、password都各自维护。实际操作中我通常会同时建三个环境dev、test、prod。每个环境里放相同的变量名但值不一样。切换环境的时候点击右上角的环境下拉框选一下就好。请求里面的{{baseUrl}}不需要做任何修改发送出去的时候自然解析成当前环境下的值。一个容易忽略的点环境变量同样区分Initial Value和Current Value。Current Value是本地生效的覆盖值适合放临时token这类东西Initial Value是环境模板自带的默认值适合放环境公共配置。这样设计有个好处你在本地执行测试时修改了Current Value不会污染环境模板本身。2.3 局部变量脚本里的临时值局部变量可以通过pm.variables.set(key, value)来创建生命周期局限在当前请求的脚本执行周期内。它的最大特点是临时、快速、不影响其他请求。举一个我常用的场景我要给一个下单接口生成一个临时订单号它只在这个请求里用一次不需要存到环境变量里也不想污染全局变量。那就直接在Pre-request Script里生成并set成局部变量然后在请求体里用{{orderId}}引用。同类的场景还有循环逻辑里的游标或者只在某一步骤内使用的参数。局部变量每次请求结束就消失了不会留下脏数据。2.4 数据变量数据驱动测试的输入源如果你用Collection Runner批量跑接口测试数据变量就派上用场了。你可以在Runner里导入一个CSV或者JSON文件Postman会逐行或逐条读取把每一行的字段作为变量注入到请求中。CSV文件的第一行是字段名后面每一行是一条测试数据JSON文件则是一个对象数组每个对象是一条测试数据。在请求中直接通过字段名引用比如{{username}}、{{expectCode}}。这个机制做数据驱动的接口测试非常顺滑可以一次性验证几十个典型输入。2.5 优先级规则局部 数据 环境 集合 全局我见过太多人栽在变量优先级上。Postman官方定义的优先级从高到低是局部变量、数据变量、环境变量、集合变量、全局变量。把这个规则记成一个简单的口诀越“临时”、越“具体”的变量越优先。全局变量是所有人都能用的公共设置环境变量是当前环境下的设置集合变量是当前集合的设置数据变量是当前这组测试数据的设置局部变量是当前这个请求的设置。范围越小越能覆盖范围更大的同名变量。3. 创建、引用与动态更新变量的全链路操作指南理解了分类下面直接上手。这一节覆盖变量的创建方式、引用位置、脚本读写API以及一个能直接套用的token自动传递案例。3.1 三种创建变量的方式方式一界面手动创建。在Environments面板里加环境或者切到Globals页面直接写Key和Value。这种方式适合初始化和维护静态值。方式二脚本创建。在Pre-request Script或Tests标签页里用pm.environment.set()、pm.globals.set()、pm.variables.set()动态写入。这种方式适合运行时产生的值比如登录接口返回的token。方式三文件导入。如果你已经有一套环境配置的JSON文件可以直接点击Import导入。团队协作时常常通过这种方式同步环境配置。3.2 变量能在哪些地方被引用变量的引用语法是{{变量名}}能用的位置比很多人想的多URLhttps://{{baseUrl}}/api/v1/usersURL参数?page{{pageNo}}size{{pageSize}}请求头Authorization: Bearer {{accessToken}}请求体raw/JSON{userId: {{userId}}}注意JSON字符串里的变量要放在双引号之内断言pm.expect(jsonData.code).to.eql(pm.environment.get(expectCode))脚本内部通过pm.variables.get(xx)获取3.3 脚本中读写变量的核心APIPostman的脚本环境推荐使用pm.*语法这是较新版本的标准写法。旧教程里的postman.setEnvironmentVariable()是早期写法功能一样但既然官方都在推新API建议新项目直接用pm.*。操作写法读环境变量pm.environment.get(key)写环境变量pm.environment.set(key, value)读全局变量pm.globals.get(key)写全局变量pm.globals.set(key, value)读集合变量pm.collectionVariables.get(key)写集合变量pm.collectionVariables.set(key, value)读写局部变量pm.variables.get(key)/pm.variables.set(key, value)这里有个细节容易弄混pm.variables.get(key)在读取时的优先顺序也是按照前面说的变量优先级来的。也就是说如果你只想知道某个变量的当前解析值用它最省心如果你明确要读环境变量就用pm.environment.get()。3.4 案例登录token自动获取并传递给后续请求这个案例是变量使用里最经典的场景流程大概是这样第一步创建一个环境比如叫dev在环境变量里预置baseUrl、username、password这些值。第二步新建一个登录请求URL写https://{{baseUrl}}/api/login请求体里引用{{username}}和{{password}}。第三步在登录请求的Tests标签页里写提取脚本const resp pm.response.json(); if (resp.code 0 resp.data.accessToken) { pm.environment.set(accessToken, resp.data.accessToken); } else { console.log(登录失败, resp); }第四步在后续业务请求的请求头里写Authorization: Bearer {{accessToken}}。到这里整套流程就闭环了你手动跑一次登录请求Postman自动把token写入当前环境变量后续任何请求只要引用{{accessToken}}都会自动携带正确的token。之后token过期只需要再跑一次登录请求后面的请求无需任何改动。再进一步还可以在集合的Pre-request Script里做“token失效自动重登”的逻辑每次发送请求前先判断一下当前环境变量里有没有token没有就先登录一次再继续。不过这个方案要小心并发请求场景下的重复登录后面踩坑部分会讲。4. 变量优先级冲突排查为什么改了值却不生效这一节专门讲“变量明明改了请求里却还是旧值”这类问题。很多人遇到这种情况第一反应是清缓存、重启Postman其实最大的可能就是变量优先级在捣乱。4.1 用优先级规则复盘一个实际场景假设你在全局变量里定义了token global-token在dev环境变量里也定义了token env-token。请求里写的是{{token}}Postman会取哪个答案是env-token。原因就是环境变量优先级高于全局变量。反过来如果你在请求的Pre-request Script里执行了pm.variables.set(token, local-token)那么当前请求里的{{token}}会解析为local-token。脚本甚至还能覆盖环境变量这就是局部变量优先级最高的含义。4.2 场景复现环境变量为什么不生效很多人的排查困境是这样的明明在dev环境里把baseUrl值从http://a.com改成了http://b.com但发送请求时走还是http://a.com。此时不要急着删请求先按顺序检查这几项右上角当前选择的环境是不是dev如果选的是No Environment那环境变量里的值当然不生效。集合根目录的Variables标签页里有没有也定义了一个baseUrl有的话集合变量优先级会低于环境变量但如果你没有在环境变量里设置baseUrl集合变量就会生效。脚本里是否在某次运行时往局部变量或全局变量里写过同名字段局部变量优先级最高全局变量虽然最低但同名时也会让人困惑。这种同名变量分散在多个作用域的情况在团队共享集合之后特别常见。排查思路就一句话按照优先级顺序从高到低逐个检查{{xxx}}这个变量名在所有作用域里的值。4.3 排查变量的三个关键动作动作一用右上角的“眼睛”图标快速查看当前环境变量和全局变量的实际值。点击环境名称旁边的眼睛图标会弹出当前环境的变量列表能直接看到Initial Value和Current Value。这是排查问题的第一步。动作二在脚本里临时加一行console.log(pm.variables.get(baseUrl))看Postman当前解析出的到底是什么值。这个打印结果会出现在Postman底部的Console面板里比肉眼猜要快得多。动作三检查Console面板里每个请求的实际请求URL。Console的请求记录里会显示替换后的完整URL你直接看发出的请求是什么就能判断变量解析是否正确。4.4 Initial Value与Current Value的迷思还有一个常见坑环境变量面板里有两个Value列Initial Value和Current Value。很多人在Initial Value里改了值然后就以为生效了但实际发送请求时用的是Current Value。Current Value是运行时的实际值Initial Value是你初始化/导入时的默认值。如果你在面板里改的是Initial Value而Current Value已经有了旧值Postman会优先使用Current Value。这时候最好的做法要么把两个值都改掉要么点Current Value旁边的重置按钮让它和Initial Value保持一致。5. 动态变量与数据驱动批量测试场景下的进阶玩法变量不止能存固定值Postman还内置了一批动态变量加上脚本能力可以组合出不少高级操作。5.1 内置动态变量直接给请求里写{{$guid}}这类内置变量Postman会在发送时自动生成随机值。常用的有这些内置变量含义示例输出{{$guid}}全局唯一标识符5b9d0f3c-3b8a-4f2b-8a1a-6b5f3a0a0a0a{{$timestamp}}当前Unix时间戳1743993600{{$isoTimestamp}}ISO格式时间戳2025-04-07T12:00:00.000Z{{$randomInt}}0到1000的随机整数723{{$randomEmail}}随机邮箱地址john.doeexample.com这些动态变量在做并发创建、重复提交、唯一性校验时很有用。比如测试“同一用户必须用唯一邮箱注册”直接每次用{{$randomEmail}}生成一个新邮箱。5.2 自定义随机数据生成内置动态变量毕竟有限更灵活的方式是在脚本里自己生成数据。这里分享一个我常用的思路// Pre-request Script: 生成随机用户名 const randomName user_ Date.now() _ Math.floor(Math.random() * 1000); pm.variables.set(randomName, randomName);另外很多人不知道Postman的脚本运行环境里内置了lodash和dayjs你可以直接用_.xxx或者dayjs().format()不需要自己实现一堆工具函数。比如生成一个随机的手机号const prefix [139, 138, 137, 136]; const phone prefix[Math.floor(Math.random() * prefix.length)] String(Math.floor(Math.random() * 100000000)).padStart(8, 0); pm.variables.set(randomPhone, phone);5.3 用CSV做数据驱动的接口批量测试数据驱动是我做接口回归时最常用的方式。步骤不复杂第一步准备好CSV文件username,password,expectCode alice,123456,0 bob,123456,1001 carol,123456,0第二步在Collection Runner中点击Run选择集合后在Data栏导入CSV文件。第三步请求体里引用变量名{ username: {{username}}, password: {{password}} }第四步在断言里用pm.environment.get(expectCode)或者直接pm.variables.get(expectCode)读取当前迭代的期望值判断接口返回是否符合预期。这样跑一轮下来每条测试数据都会单独执行一次请求结果可以在Runner的报告里逐条查看。配合变量提取还能把断言结果汇总到测试报告中。JSON数据文件同理只需要是一个对象数组每个对象的字段名与请求中的变量名对应即可。5.4 分页循环中的变量状态维护接口分页测试也是变量使用的高频场景。一种常见做法是用postman.setNextRequest()实现循环再配合变量更新游标。思路是第一个请求获取总页数并把当前页码初始化为1下一页请求里把页码加1后继续跳转到下一页直到页码超过总页数结束循环。// 第一个请求的Tests const resp pm.response.json(); pm.environment.set(totalPages, resp.data.totalPages); pm.environment.set(currentPage, 1);// 后续每个请求的Tests const current pm.environment.get(currentPage); const total pm.environment.get(totalPages); if (current total) { pm.environment.set(currentPage, current 1); postman.setNextRequest(获取下一页数据); }这里有个容易踩坑的地方循环请求里要时刻关注currentPage的值是否被重置尤其在Runner中多次运行时环境变量里残留的上一次循环值会直接干扰下一次执行。如果环境变量的值能通过初始值重置推荐在运行前先把页码变量归零。6. 变量使用中容易翻车的细节与避坑记录最后这部分把我这几年用Postman变量过程中踩过的坑集中整理一下。很多问题不是看文档能看出来的全是实际操作时才会暴露。6.1 变量值里的特殊字符是个隐性杀手如果变量值里带有、#、空格、中文等字符直接放在URL里可能解析出问题。比如{{keyword}}的值为hello world co拼进URL后空格和会让请求变得不可预测。解决办法有两个一是写脚本时提前对变量做编码二是不要依赖Postman自动处理手动把控编码时机const keyword hello world co; pm.environment.set(encodedKeyword, encodeURIComponent(keyword));请求里用{{encodedKeyword}}就不会出现乱码或截断问题。另外在JSON请求体里引用变量时千万别写成{name: {{name}}}。JSON要求字符串带引号正确写法是{name: {{name}}}。如果你把变量值当成裸文本塞进去Postman虽然做了文本替换但你得到的可能是一段不合法JSON。6.2 响应取值失败导致变量变成undefined在Tests脚本里提取响应字段时如果路径写错pm.response.json()返回的对象里可能没有对应字段。这时直接pm.environment.set(accessToken, undefined)Postman会把这个变量值设置成字符串undefined。后面所有引用这个变量的请求都会带着一个字面量undefined去请求接口非常隐蔽。所以我在提取值时习惯先做一层存在性判断const resp pm.response.json(); const token resp resp.data resp.data.accessToken; if (token) { pm.environment.set(accessToken, token); } else { console.log(未获取到token响应体是, JSON.stringify(resp)); }这样即使路径写错至少日志里能清楚看到响应体长什么样而不是揣着个“undefined”继续跑。6.3 敏感信息别放全局变量前面提过一次这里再强调一下全局变量、环境变量在导出的时候Initial Value都会跟着环境文件走。如果你在Initial Value里存了数据库密码、云服务密钥分享环境文件给同事或者上传到公共仓库就等于把这些信息暴露给了不该看到的人。我的做法是环境变量里只放脱敏的默认值或临时值真正的生产密码通过加密变量Postman的商业版支持Secret变量或者动态获取的方式处理。如果实在需要共享环境导出前一定要检查一遍变量值把敏感字段清空或改成占位符。6.4 脚本执行顺序带来的变量读取延迟Postman单个请求的执行顺序是Pre-request Script先执行然后发送请求最后执行Tests。很多人的困惑来自这个顺序在Tests里写pm.environment.set(token, xxx)然后马上在同一个请求的断言里用pm.variables.get(token)理论上能取到但如果你在下一次请求的Pre-request Script里想读它是没问题的可如果你试图在同一个请求的Pre-request Script里读上一个请求Tests里写入的值当然读不到因为那个请求还没执行到Tests。如果你有“请求前获取最新变量”的需求就得想办法把逻辑放在集合级的Pre-request Script里或者在请求之间显式串联依赖关系。6.5 循环执行时变量被意外重置用Collection Runner跑集合时每次迭代之间环境变量和全局变量是“延续”的不会自动重置。这个特性有时是好事但有时是坑。比如你在一组测试里设置了一个累加器第一轮跑完了值是10第二轮开始没重置所有结果都会被这个残留值污染。类似的问题在分页循环示例中也提到过。我的习惯是每次Runner运行之前在集合的Pre-request Script里统一把关键变量重置到初始状态或者为关键变量单独准备一套“运行前清理”的请求。写在最后从我自己多年的使用感受来说Postman里变量玩得转不转直接决定接口调试效率的上限。把登录token自动传递、环境的灵活切换、数据驱动批量测试这套组合拳打熟练之后再复杂的接口集合也能理出清晰的结构。最后分享两个我很喜欢的小技巧一是给环境变量命名时统一使用前缀区分比如apiBaseUrl、dbHost、accessToken避免命名冲突二是把每个环境都复制一份不带敏感信息的“模板环境”用于团队新人初始化。这两个习惯帮我省掉了不少沟通成本希望你也能用得上。