Postman JSON body中变量必须显式加引号才能作为字符串使用，否则导致JSON解析失败；数值型变量需防精度丢失，大整数应转为字符串处理。
Postman JSON body 中变量未加引号导致解析失败
Postman 在 raw JSON 模式下做变量替换时，不会自动为变量值添加双引号。如果变量值是字符串，但你写成 {{user_name}} 而不是 "{{user_name}}"，最终拼出来的就不是合法 JSON，服务端解析时会报 Unexpected token 类错误（比如 Unexpected character 'b'），本质是把变量值当成了未加引号的标识符或关键字。
常见错误现象：
- 请求体看起来“长得像 JSON”，但 Postman 控制台或服务端报
JSON parse error - 用
pm.request.body.raw打印出来后，发现变量位置直接裸露（如"name": admin2，缺引号） - 变量值含空格、特殊字符或数字开头时更容易暴露问题
解决办法很简单：
- 所有在 JSON 字段值位置使用的变量，必须显式包裹双引号：
"{{variable_name}}" - 如果是数值类型变量（如
user_id），且你希望它保持 JSON number 类型，就不要加引号；但要注意：Postman 变量本身是字符串，{{user_id}}会被当作字符串插入，若不加引号，会导致语法错误；若加了引号，又变成字符串——此时应改用脚本动态构造，而非纯 raw 替换 - 不确定类型时，先用
console.log(pm.request.body.raw)或tests["raw"] = pm.request.body.raw把实际发出的内容打出来，粘到 JSONLint 校验
Postman 变量在 JSON 中被双重转义
当你在 Tests 脚本里用 pm.environment.set("token", responseJson.access_token) 存了一个带双引号或反斜杠的值（比如 JWT），再在后续请求 body 中引用 {{token}}，Postman 不会对变量内容做任何转义处理——它只是原样替换。如果原始值里已有 " 或 \n，而你又把它放在 JSON 字符串字段中，就会破坏结构。
典型场景：
- 从登录响应提取 JWT 并存为环境变量，然后在 Authorization header 的 Bearer 后直接填
{{token}}—— 这没问题，因为 header 不是 JSON - 但若把这个
{{token}}塞进一个 JSON body 的字段里，比如{"auth": "{{token}}"}，而token值本身含"，那整个 JSON 就会提前闭合
应对方式：
- 避免在变量中存未经清洗的原始响应字段（尤其是 JWT、HTML 片段、日志文本）
- 如必须使用，改用 Pre-request Script 动态构造 body：
pm.request.body.raw = JSON.stringify({ auth: pm.environment.get("token") });，由JSON.stringify自动处理转义 - 不要依赖 raw + 变量拼接处理复杂值；越复杂的值，越要交给脚本控制序列化过程
curl 和 Postman 对 JSON 变量的处理逻辑完全不同
很多人在 Postman 里调通了，转头用 curl 写同样逻辑却失败，不是因为变量没设对，而是根本没变量这回事——curl 命令行里没有运行时变量系统。所有所谓“变量”都是 shell 层面的字符串替换，受引号规则、转义层级、平台差异（bash vs PowerShell）支配。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
关键区别：
- Postman 的
{{var}}是在发送前由客户端引擎替换，发生在 JSON 解析之前 - curl 的
$VAR或${VAR}是 shell 在执行命令前展开，若没用单引号保护，JSON 中的双引号、$、反斜杠全都会被 shell 吞掉或误解释 - Postman raw 模式默认校验 JSON 语法（有红波浪线提示），curl 完全不校验，错在哪得靠服务端报错反推
实操建议：
- 调试阶段，优先用 Postman 的
Code按钮生成 curl 命令，而不是手写——它会自动处理引号和转义 - 若需手写，body 必须用单引号包裹整个 JSON 字符串：
curl -H 'Content-Type: application/json' -d '{"id": '"$ID"'}' https://api.example.com，注意内外引号嵌套技巧 - Windows 用户尤其警惕 PowerShell 的
$和@符号，建议切到 cmd 或用--data-binary @file.json绕过命令行解析
数值型变量在 JSON 中精度丢失
Postman 内部用 JavaScript Number 类型存储变量值，而 JS 的 Number 是 IEEE 754 双精度浮点数，无法精确表示超过 253 − 1（即 9007199254740991）的大整数。当你从响应中提取一个长 user_id（如 337292419039105024）并设为环境变量，再在 JSON body 中引用，实际存入和替换的可能是 337292419039105000——末尾几位被抹零。
这不是 Postman bug，是 JS 语言限制。表现就是：
- 接口返回的 ID 正确，但下游服务查不到记录
- 对比
pm.environment.get("user_id")和原始响应里的值，发现不一致
绕过方法只有两个：
- 始终以字符串形式处理大整数：在 Tests 脚本中用
pm.environment.set("user_id", "" + responseJson.user_id)或responseJson.user_id.toString() - 在 JSON body 中写成
"user_id": "{{user_id}}"（加引号），确保它作为 JSON string 发送，而非 number
别指望 Postman 自动识别“这个看着像数字，但我应该当字符串用”——它不会。
