Postman添加查询参数最稳妥方式是使用Params标签页手动填写,支持同名多值和自动URL编码;Pre-request Script需先清空再添加以防重复;URL栏手写参数不可维护且不自动编码;须区分Query、Path、Body参数职责,注意环境变量未生效时的默认值处理。

Postman 添加多个查询参数本身没有技术门槛,但容易因参数重复、编码错误或环境变量未生效导致请求失败。关键不是“能不能加”,而是“加得对不对”。
Params 标签页里直接填是最稳的方式
这是最直观、最不易出错的方法,适合手动测试或参数固定场景。
- 打开请求 → 切到
Params标签页 → 每行填一个key和value - Postman 会自动 URL 编码(比如空格变
%20,中文变 UTF-8 编码),无需手动处理 - 如果某参数要传多次(如
filter=active&filter=pending),直接填两行相同key即可 —— Postman 支持同名多值,且不会去重 - 注意:这里填的参数只影响当前请求,不修改原始 URL 输入框内容;发送后 URL 栏会实时更新成带参的完整地址
Pre-request Script 动态加参时,addQueryParams 容易重复追加
用脚本动态加参很灵活,但 addQueryParams 不是“覆盖”,而是“追加”,稍不注意就会让同一个参数出现两次甚至更多。
- 比如已存在
userId=100,再执行pm.request.url.addQueryParams("userId=200"),最终 URL 会变成?userId=100&userId=200 - 正确做法是先清空再设:
pm.request.url.query.clear(); pm.request.url.query.add({key:"userId", value: "200"}); - 若需保留部分原有参数,用
pm.request.url.query.all()遍历筛选,再用clear() + add()重建 - 环境变量取值失败(如
pm.environment.get("token")返回undefined)会导致参数值为字符串"undefined",建议加默认值:pm.environment.get("token") || ""
GET 请求中,URL 栏手写参数和 Params 填写效果一样,但有隐性区别
两者最终都生成相同的 HTTP 请求,但维护性和可读性差异明显。
Postman 12.27.7 Windows x64 官方安装包,适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力,以及接口规范标签管理改进,适合受限网络测试与规范资源组织场景。
- 在 URL 栏直接写
https://api.example.com/users?role=admin&status=active—— 快速,但无法复用环境变量,也不能被 Collection Runner 批量替换 - 在
Params里填,配合环境变量(如{{base_url}}、{{env_token}})—— 可维护性强,适合团队协作和自动化测试 - URL 栏手写时若含未编码的特殊字符(如空格、
#、&),Postman 不会自动修正,可能触发 400 错误;而Params标签页输入会强制编码,更安全
多个参数共存时,注意 Query、Path、Body 的职责边界
不是所有参数都该塞进 query —— 混用类型会导致后端解析失败或行为异常。
-
Path Parameters(如/users/:id)必须体现在 URL 路径中,不能放Params标签页;Postman 会把冒号后占位符(如:id)高亮为可编辑字段 -
Query Parameters适合过滤、分页、排序等非资源标识类数据(如page=2&limit=10&sort=name) -
Body(尤其是x-www-form-urlencoded)虽也能传键值对,但 GET 请求不应带 Body;若后端同时从 query 和 body 读同名参数,结果不可控 - 混合使用时,务必确认后端框架的解析优先级(例如 Spring Boot 中
@RequestParam默认只读 query,@PathVariable只读 path)
真正容易被忽略的是参数生命周期:Params 标签页填的值不会自动同步到环境变量,Pre-request Script 里改的参数也不会持久化到请求模板中。每次切换环境或重开 Postman,都要重新核对参数来源是否可靠。










