Postman自动URL编码与手动encodeURIComponent冲突会导致双重编码（如%2520），因Params默认编码后脚本又编码一次；应统一在Pre-request Script中控制编码逻辑，禁用Params自动编码或跳过已编码字段。
Postman自动URL编码和你手动encodeURIComponent冲突
Postman在Params标签页里填的参数，只要没关掉“Trim keys and values”，它就会自动做一次URL编码——比如空格变%20、&变%26。如果你又在Pre-request Script里对同一个参数再调一次encodeURIComponent，就等于编码了两次。服务器收到%2520（即%20被再次编码），解码一次得%20，再解一次才得空格，但多数后端只解一层，结果就是字段值错乱。
常见表现：
- 请求URL里出现
%2520、%2526这类嵌套编码 - 后端日志里看到参数值是
start%2520with，而不是预期的start%20with - 用cURL或Apipost能通，Postman死活不行
排查建议：
- 先关掉Params里的参数，把所有参数挪到
Pre-request Script里拼接，统一控制编码逻辑 - 如果必须用Params，就在脚本里跳过对该字段的二次编码，改用
pm.request.url.query.get("key")取原始值再处理 - 检查是否启用了
Trim keys and values设置（Settings → General → Trim keys and values in request body），它会影响form-data和x-www-form-urlencoded，但对Params也有隐式作用
Content-Type为x-www-form-urlencoded时，空格被编码成+还是%20
这是W3C表单规范和URI标准打架的典型现场。application/x-www-form-urlencoded要求空格编码为+，而RFC 3986规定URI中空格必须是%20。Postman默认按URI规则走，所以Params里空格变%20；但如果你用Body → x-www-form-urlencoded，它又会按表单规范转成+。两者混用，mock数据和实测就不一致。
解决方案很直接：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 统一用
%20：在Pre-request Script里对所有待提交的字符串先encodeURIComponent，再.replace(/\+/g, '%20') - 避免混用：别在Params里填一部分参数、又在Body里填另一部分同名参数，尤其当Content-Type是
x-www-form-urlencoded时 - 后端若强制要求
+，可在脚本里用encodeURI(str).replace(/%20/g, '+')，但需确认服务端真能正确识别
Pre-request Script里变量被多次赋值导致编码叠加
很多人写脚本时习惯在开头pm.environment.set("token", ...)，然后在后续逻辑里又pm.environment.set("token", CryptoJS.enc.Base64.stringify(...))，结果第二次set其实是对已编码过的字符串再编码。更隐蔽的是环境变量和全局变量混用：pm.variables.set和pm.environment.set作用域不同，但都可能被重复覆盖。
关键判断点：
- 打开Postman Console（View → Show Postman Console），在脚本里加
console.log(pm.environment.get("param"))，看每次迭代时值是不是越来越长 - 检查脚本顶部有没有
const param = pm.environment.get("param") || "default"这类兜底逻辑——如果环境变量已是编码后值，再套一层就炸 - Collection Runner跑多行数据时，务必确认每轮迭代前清空相关变量，比如在脚本开头加
pm.environment.unset("temp_encoded_param")
响应体中文乱码连带引发的编码误判
有时候你以为是参数编码错了，其实只是Postman把响应当成了错误编码来显示。比如服务器返回UTF-8的JSON，但Header里漏写了Content-Type: application/json; charset=utf-8，Postman就可能按ISO-8859-1解析，中文全变。你一急，回头去改请求参数编码，越调越偏。
快速验证方法：
- 点开响应右上角的
Save Response → Save to file，用VS Code或Notepad++以UTF-8重新打开，看中文是否正常 - 在Console里执行
pm.response.text()，复制输出内容粘贴到在线编码检测工具（如sina.cn的编码检测页），确认真实编码 - 如果确实是响应编码问题，在
Tests脚本里加pm.response.to.have.header("Content-Type", /charset=utf-8/)作为断言，推动后端补Header
真正容易被忽略的，是Params自动编码和脚本手动编码的边界模糊——Postman不告诉你它什么时候悄悄动了你的字符串，你得自己盯住Console里每一行log，比对输入、脚本输出、最终URL三者是否一致。
