加号在URL参数中被当作空格处理，因application/x-www-form-urlencoded规范规定+等价于空格，%2B才是加号；Params标签页不自动编码，应改用Body中的x-www-form-urlencoded或form-data方式发送。
加号在 URL 参数中会被当成空格处理，不是 Postman 的 bug，是 HTTP 协议和 application/x-www-form-urlencoded 编码规则决定的。 你填在 Params 标签页里的参数，最终会拼到 URL 后面，而 URL 中的 + 就是空格的合法编码形式——所以后端一解码，+ 就没了，变成空格。
Params 标签页传 + 必然出错
这是最常踩的坑。比如你填：
- Key：
phone，Value：138+1234+5678 - Postman 自动拼成：
?phone=138+1234+5678 - 后端用
request.getParameter("phone")拿到的是："138 1234 5678"
原因很直接：URL 查询字符串默认按 x-www-form-urlencoded 解析，其中 + ≡ 空格，%2B 才是真正的加号。但 Params 标签页不帮你做这层转义，它只原样拼接。
用 Body → form-data 或 x-www-form-urlencoded 替代 Params
只要不让参数出现在 URL 上，就能绕过这个编码陷阱。两种方式都行，区别在于：
-
form-data：适合含文件、或值里有换行/二进制数据的场景；Postman 会自动加boundary，后端用@RequestParam或MultipartFile接收 -
x-www-form-urlencoded：更轻量，Postman 会帮你把+自动转成%2B，后端收到的就是原始字符串（前提是 Content-Type 正确设为application/x-www-form-urlencoded）
操作路径：切换到 Body 标签页 → 选中对应类型 → 填 Key/Value → 发送。此时请求体里是 phone=138%2B1234%2B5678，后端解码后还原为 138+1234+5678。
需要手动编码时，别信浏览器地址栏自动补全
如果非得走 Params（比如某些 GET 接口强制要求参数在 URL），那就必须自己对 + 做 URL 编码：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 错误写法：
138+1234+5678（浏览器或 Postman 不会二次编码） - 正确写法：
138%2B1234%2B5678（%2B是+的标准 URL 编码） - 其他易错字符：空格要写
%20（不是+），#要写%23，&要写%26
别依赖 Postman 的“自动编码”提示——它只在 Body 的 x-www-form-urlencoded 模式下生效，Params 模式下完全不干预。
后端接收不到值？先看 Content-Type 和注解是否匹配
常见连环错：
- 你在 Body 里选了
raw+JSON，却用@RequestParam接收 → 必然为null - 你用了
form-data，但后端写了@RequestBody UserInfo user→ 也收不到 - 你发的是
x-www-form-urlencoded，但没设 Header 的Content-Type→ 某些框架（如 Spring）会 fallback 到默认解析逻辑，导致+又被当空格
对应关系必须严格对齐：form-data → @RequestParam 或 @RequestPart；x-www-form-urlencoded → @RequestParam；raw + JSON → @RequestBody。
真正容易被忽略的是：加号问题从来不是孤立的，它总和编码方式、传输位置（Query/Body）、后端解析策略绑在一起。调不通时，不要只盯着值本身，先抓包看一眼实际发出的请求体和 Header，比反复改参数更省时间。
