Params标签页仅拼接URL查询参数（?key=value形式），不涉及Body、Headers或认证；填错位置（如JSON误填Params）会导致后端无法接收数据，引发400错误。
Params 标签页填的是 URL 查询参数（query string）
Postman 的 Params 标签页只负责拼接到 URL 末尾的键值对，也就是 ?key1=value1&key2=value2 这部分。它不会影响请求体（Body）、Headers 或认证信息。如果你在接口文档里看到类似 /api/users?status=active&limit=10 的地址，所有 ? 后面的内容就该填在这里。
常见错误是把本该放在 Body 里的 JSON 数据误填进 Params，结果后端收不到字段，或者返回 400 Bad Request —— 因为服务端在 Body 里找数据，而你根本没发 Body。
填 Params 时必须注意 URL 编码和空格处理
Postman 默认会对 Params 中的值自动做 URL 编码（比如空格变 %20，中文变 %E4%BD%A0），多数情况这是好事；但如果你明确需要原始字符（例如某些老系统要求空格不编码），就得手动在值前后加双引号，或者改用 Body → x-www-form-urlencoded 模式（它也支持编码控制）。
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
- 含空格的值：
q=hello world→ 自动变成q=hello%20world - 含斜杠或问号：
path=/v1/api?test=1→ 全部被编码，path=%2Fv1%2Fapi%3Ftest%3D1 - 不想被编码？改用
Body → raw → text/plain手动构造完整 URL（不推荐，破坏可维护性）
Params 和 Body 同时存在时，后端怎么区分
HTTP 协议本身允许同时存在查询参数和请求体，但是否接受、如何解析，完全取决于后端实现。比如：
- RESTful API 通常用
Params控制分页（page,limit）、过滤（status,name），用Body传创建/更新的数据 - GraphQL 请求几乎从不用
Params传 query，而是统一走Body → raw → GraphQL - 如果后端用 Spring Boot，
@RequestParam对应Params，@RequestBody对应Body，填错位置会导致参数绑定失败，日志里常出现MissingServletRequestParameterException
调试 Params 填写是否生效：看发送前的 URL 预览
Postman 右上角有个「Code」按钮，点开能看到它实际要发的 curl 命令。重点检查 curl -G（表示 GET + 参数在 URL）还是 curl -d（表示 POST + 数据在 body）。更直接的办法是打开 Params 标签页后，盯着 URL 输入框——只要填了内容，URL 就会实时追加 ?xxx=yyy。如果没变化，可能是：
- 当前请求方法不是
GET或DELETE（某些团队约定 POST 也带查询参数，但 Postman 不强制限制） - 你填的是
Key为空，或Value为空且未勾选Encode（Postman 会忽略空值行） - 用了环境变量但变量未定义，显示为
{{missing_var}}，此时 URL 不会展开
真正容易被忽略的，是环境变量嵌套和 URL 编码的双重作用——比如 {{base_url}}/search?q={{keyword}} 中，如果 keyword 是 “a b”，它会被编码两次，导致后端收到 “a%2520b”。
