用Postman发带查询参数的GET请求，应统一在Params标签页填写键值对，而非手动拼接URL；Postman自动URL编码，避免乱码或解析错位，且URL输入框仅作预览，真实请求以Preview Request为准。
带查询参数的接口，用 Postman 发 GET 请求就行，但很多人卡在参数没生效、URL 被自动编码、或误把参数塞进 Body 里——这三类问题占了实际调试中 80% 以上的“发不出去”报错。
怎么填查询参数（不是 URL 拼接）
Postman 提供了专门的 Params 标签页来管理查询参数，比手动拼 URL 更可靠、更可维护。
- 在请求界面点击
Params选项卡（不是Body或直接改 URL 输入框） - 每行填一个键值对：
key列写参数名（如name），value列写值（如xia） - Postman 会自动 URL 编码（比如空格变
%20），无需手动处理 - 填完后，URL 输入框右侧会实时显示拼好的完整地址，例如：
http://cx.shouji.360.cn/phonearea.php?name=xia&age=13
为什么手动拼 URL 容易出错
直接在 URL 输入框里写 https://api.example.com/search?keyword=hello world 看似简单，但实际会触发两个隐性问题：
- 空格、中文、斜杠等字符未被编码 → 服务器收到乱码或 400 错误，错误信息常是
400 Bad Request或invalid URI - 参数值含
&或=（比如密码字段）→ URL 解析错位，后半段参数直接丢失 - 协作时难以复用：别人复制 URL 时可能漏掉问号后的内容，或误删了某个
&
GET 请求要不要设 Content-Type？
不需要。GET 请求没有请求体（Body 是灰色禁用状态），所以 Content-Type 头对它完全无效，设了也白设，还可能干扰某些网关校验。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 真正需要关注的头只有：
Accept（告诉服务器你想要什么格式响应）、Authorization（如有认证）、Cookie（如需会话保持） - 如果接口文档明确要求带
Content-Type: application/json才放行，那大概率它其实是个伪装成 GET 的怪异设计，建议确认是否应为 POST + 查询参数放 URL - Postman 默认不自动加任何
Content-Type，别手贱点开Headers表格随便加一行
什么时候该用 POST 而不是 GET 带参
当你的“查询条件”实际是复杂结构、敏感数据或超长字符串时，GET 就不合适了——URL 长度限制（通常 2KB 左右）、服务端日志泄露风险、缓存污染都是真问题。
- 典型信号：
keyword值超过 500 字符、含 base64 图片数据、有token或signature字段 - 正确做法：切到
POST方法，Body选raw+JSON，把原来 URL 里的参数全挪进去，同时把Content-Type: application/json加到Headers中 - 注意：此时 URL 里只保留基础路径，比如
https://api.example.com/search，所有条件都走 Body
最容易被忽略的一点：Postman 的 Params 表格一旦填写，就不再受 URL 输入框编辑影响——哪怕你手动删掉 URL 里的 ?xxx，点 Send 时参数依然会加上。调试时务必看右上角「Preview Request」里的真实发出 URL，而不是只盯输入框。
