Postman变量系统只存储字符串，导致JSON数字被转为字符串；需在Pre-request Script中用parseInt/parseFloat等显式转换并JSON.stringify()生成请求体。
Postman 里 JSON 的数字被自动转成字符串？先看是不是变量类型问题
Postman 本身不会主动把 JSON 中的数字“变成”字符串——但当你用 pm.variables.set() 或 pm.environment.set() 存一个数字（比如 123），再通过 {{var}} 插入到 raw body 时，Postman 默认把它当字符串拼进去。结果就是 {"id": "123"} 而不是 {"id": 123}。
根本原因：Postman 的变量系统只存字符串值。哪怕你设的是 pm.variables.set("id", 456)，底层也转成了字符串 "456"。
- 检查方式：在 Pre-request Script 里加
console.log(typeof pm.variables.get("id"))，输出一定是"string" - 如果你需要保留数字类型，必须在生成 JSON 字符串前手动做类型转换，而不是依赖变量插值
- 别在 Body → raw 里直接写
{"id": {{id}}}—— 这种写法永远会把{{id}}当字符串处理
JSON.stringify() 是唯一可靠的方式
想让数字、布尔、null 等保持原始类型，必须用 JavaScript 构造对象再序列化。不能靠变量插值拼接。
正确做法是在 Pre-request Script 中构造 JS 对象，然后用 JSON.stringify() 转成字符串，再塞进请求体：
const payload = {
id: parseInt(pm.variables.get("id")),
active: pm.variables.get("active") === "true",
score: parseFloat(pm.variables.get("score"))
};
pm.request.body.raw = JSON.stringify(payload);
-
parseInt()和parseFloat()必须显式调用，否则"123"还是字符串 - 布尔值不能靠
Boolean("false")—— 它返回true；得用=== "true"这类判断 - 如果变量可能为空或非数字，加个
isNaN()防御，避免NaN进入 JSON
用 iterationData 传参时数字变字符串的坑
从 CSV/JSON 数据文件读取参数时，pm.iterationData.get("id") 拿到的永远是字符串，哪怕 CSV 里写的是 123（没有引号）。
这是因为 CSV 解析器统一按文本处理所有字段；JSON 数据文件里如果写 {"id": 123} 是合法的，但 Postman 导入后仍会把 123 转成字符串存进 iterationData。
- 验证方法：在 Tests 里写
console.log(typeof pm.iterationData.get("id")) - 修复动作：和上一节一样，用
parseInt()/parseFloat()显式转 - 偷懒不可取：不要试图在 CSV 里写
"123"或="123"来“骗过”解析器——无效
Content-Type 和后端接收不匹配会让问题更难排查
即使你用 JSON.stringify() 正确生成了 {"id": 123}，如果请求头没设对，后端也可能把 123 当字符串解析（比如 Spring Boot 的 @RequestBody 遇到类型不匹配时会静默失败或报 400）。
- 确认 Header 里有
Content-Type: application/json，且值是纯文本，没多余空格 - 如果后端用 Jackson，注意它默认开启
DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY等特性，可能掩盖类型问题 - 最稳验证方式：用 Fiddler 或浏览器 DevTools 的 Network 面板，看「实际发出的请求体」是否含引号 —— 如果
"id": "123"出现了，说明前面某步又退化成字符串拼接了
真正容易被忽略的是：Pre-request Script 执行顺序早于变量插值，所以所有类型修复必须在这一步做完；一旦进入 body raw 编辑框，就只能靠字符串操作补救，代价高且不可靠。
