Params未出现在URL上最常见原因是参数行左侧复选框未勾选；其次可能是GET请求误设Body导致Params被静默丢弃；或环境变量未定义/未选对环境；或Pre-request Script覆盖了手动参数。
Params 表格里的参数没出现在 URL 上？先看启用状态
Postman 的 Params 标签页里填了参数，但发送请求后抓包或看响应日志发现 URL 干干净净，一个查询参数都没拼上——最常见原因是参数被“关掉了”。Params 表格每行左侧有个复选框，默认是勾选的，但手动点过就会取消，此时该参数不会参与 URL 构造，也不会报错、没有提示。
检查方法很简单：逐行确认每行开头的复选框是否处于勾选状态。尤其注意复制粘贴进来的参数、从历史记录导入的参数，或者多人协作时别人改过又没说明的情况。
- 未勾选的参数在 URL 栏和实际发出的请求中完全不可见
- 勾选状态不会自动同步到其他环境（比如 Dev 环境里关了，Test 环境里可能还开着）
- 变量引用如
{{page}}即使值存在，若所在行未勾选，照样不生效
GET 请求用了 Body，Query 参数被悄悄忽略
如果你在 GET 请求下误操作进了 Body 标签页，并填写了数据（比如 raw JSON 或 form-data），Postman 不会报错，但会静默丢弃 Params 表格里的所有参数——因为 HTTP 规范中 GET 本就不该带 body，Postman 优先信任你“主动写了 body”这个动作，于是放弃拼接 query string。
这种情况下，URL 栏看起来正常，但实际发出去的请求不含任何 Params，后端收不到查询参数。
- 解决办法：切回
Body标签页，把Body类型设为none - 再切回
Params，确认参数已勾选，URL 栏应实时更新出完整地址 - 用浏览器开发者工具的 Network 面板验证最终发出的 URL 是否含
?key=value
环境变量未解析导致 URL 显示为空或报错
当 URL 栏写的是 {{base_url}}/api/users，而 Params 里填了 page=1，但最终 URL 拼出来却是 /api/users?page=1（缺域名）或者直接显示 {{base_url}}/api/users?page=1——说明环境变量 base_url 没生效。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
变量未定义或当前环境未选对，会导致整个 URL 解析失败，进而影响 Params 的拼接逻辑（Postman 无法在 URL 不完整时安全追加 query string）。
- 检查右上角环境选择器是否选中了含
base_url定义的环境 - 在
Manage Environments里打开对应环境，确认base_url值非空且格式正确（如https://api.example.com，末尾不带/） - URL 栏里变量名必须严格匹配，大小写、下划线都不能错，
{{BaseUrl}}和{{base_url}}是两个变量
Params 和 Pre-request Script 冲突：脚本覆盖了手动参数
如果请求配置了 Pre-request Script，并且脚本里调用了 pm.request.url.addQueryParams() 或直接修改了 pm.request.url.query，那么手动在 Params 表格里填的内容很可能被脚本覆盖或清空。
这类问题多见于加签、时间戳注入等场景，脚本执行时机在请求构造前，它拿到的是原始 URL，而非你看到的“已拼好 Params”的 URL。
- 临时排查：注释掉整个
Pre-request Script，重试请求，看 Params 是否回归正常 - 脚本中若需动态加参，建议统一用
pm.request.url.query.add()，避免混用手工表格和脚本操作 - 调试时可在脚本末尾加
console.log(pm.request.url.toString())，在 Postman Console 里查看最终生成的 URL
真正容易被忽略的是：Postman 的 Params 启用状态、环境变量作用域、以及 Pre-request Script 的执行优先级，三者叠加时问题会变得隐蔽。哪怕只有一行参数没勾选，或一个环境变量拼错字母，整个查询串就彻底消失——它不会报错，只会安静地不工作。
