必须用 body 传参才能原样传递带空格的参数；params 标签页中空格会被编码为 +，导致后端解析不一致，而 JSON raw 或 x-www-form-urlencoded 可规避该问题。
Postman 里传带空格的参数，核心就一条：别让空格进 URL 查询字符串（params 标签页），否则它大概率变成 + 或被截断；想原样传递，必须走 body。
为什么 params 里的空格会出问题
URL 规范（W3C）规定：application/x-www-form-urlencoded 编码下，空格必须转成 +；而 RFC 2396 要求 URI 中空格应为 %20。Postman 的 params 区域默认按前者处理——所以你填 hello world，实际发出去的是 hello+world，后端若用严格 URI 解码器（比如某些 Java URLDecoder 默认行为），+ 就被当空格还原；但若后端用的是 Node.js querystring.parse() 或 Spring Boot 的 @RequestParam，它可能把 + 当字面量加号，导致解析失败或值错乱。
常见错误现象：
- 前端传
user name，后端收到user+name或user name（不一致） - 参数含
start with，后端condition字段变成start+with，SQL 拼接直接报错 - URL 过长被截断（浏览器对 query string 长度有限制，约 2048 字符）
用 body 传参：选 form-data 还是 x-www-form-urlencoded
两者都绕过 URL 编码，但行为不同：
-
form-data：生成Content-Type: multipart/form-data，适合混传文件 + 文本，字段名支持嵌套写法（如user[address]），但 Postman 不自动 trim 空格，需手动检查输入框前后是否有空格 -
x-www-form-urlencoded：生成Content-Type: application/x-www-form-urlencoded，本质仍是键值对，但数据在请求体里，空格会被编码为+—— 和params一样，只是不在 URL 上；如果你后端明确接受+作为空格，这个方式最轻量
实操建议：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 纯文本参数、不含文件 → 优先选
x-www-form-urlencoded，简单可靠 - 需要传文件，或字段名含点号/中括号（如
config.enabled）→ 用form-data - Postman 设置里打开
Trim keys and values in request body，可自动去掉字段值首尾空格（Settings → General）
JSON body 传参：空格最安全的方案
如果后端接口接收 Content-Type: application/json，直接在 Body → raw → JSON 里写：
{"query": "hello world", "filter": "start with"}
这种写法完全跳过 URL 编码规则，空格就是空格，引号、斜杠、换行等也都能原样保留。但注意：
- 后端必须用
@RequestBody（Spring）或req.body（Express）读取，不能依赖@RequestParam或req.query - JSON 字符串必须合法，中文无需额外编码，但双引号、反斜杠要转义
- 若参数本身是动态拼接的（比如从 Chrome 复制的请求体），粘贴后检查是否有多余缩进或不可见空格 —— Postman 不会自动清理这些
实在要用 params：手动 URL 编码空格
极少数场景必须走 URL 查询（比如调试 GET 接口、第三方回调地址限制），那就得自己控制编码：
- 把空格替换成
%20，不是+：例如q=hello%20world - Postman 不提供一键 encode 功能，但你可以用浏览器控制台快速处理：
encodeURIComponent("hello world")→"hello%20world" - 注意：不要对整个 URL 调用
encodeURI()，它不会编码/、?、=等分隔符，只对参数值部分做encodeURIComponent() - 如果参数含
+、/、?等，全部统一用%xx格式，避免后端解析歧义
真正容易被忽略的是：同一个接口，params 和 body 传参方式不能混用还指望行为一致；后端框架对不同 Content-Type 的解码逻辑差异很大，空格只是表象，背后是编码规范和解析器选择的问题。动手前先确认后端用什么方式收参数，再决定 Postman 怎么填。
