Postman传JSON数字参数需确保JSON格式正确：数字不加引号（如{"age":25}），Body选raw+JSON模式，避免form-data或x-www-form-urlencoded；后端需匹配解析配置，注意大整数精度及类型严格性。
Postman 传 JSON 数字参数本身没有特殊操作，但很多人卡在「数字被当成字符串」或「整数被自动转成浮点」这类问题上——根本原因不是 Postman 不支持数字，而是你没写对 JSON 格式，或后端解析逻辑把字段当成了字符串处理。
JSON 中的数字必须不加引号
这是最常踩的坑。只要用双引号包起来，就是字符串，不是数字。
-
{"age": "25"}→ age 是字符串，后端Integer.parseInt()可能抛异常，或 MyBatis 插入时类型不匹配 -
{"age": 25}→ age 是合法 JSON 数字，会被正确映射为 int/long - 同理：
{"price": "99.99"}是字符串；{"price": 99.99}是数字（注意：JSON 原生不区分 float/double，只认 number） - 科学计数法也合法：
{"size": 1e6}、{"offset": -3.14e-2}
Postman Body 必须选 raw + JSON，不能用 form-data 或 x-www-form-urlencoded
form-data 和 urlencoded 本质是键值对编码，所有值都会被序列化为字符串，JSON 结构会被扁平化甚至破坏。
- 错误做法：Body 选
form-data，Key 填data，Value 填{"id": 123}→ 后端收到的是字符串"{\"id\": 123}" - 正确做法：Body 选
raw，右上角下拉选JSON，直接写{"id": 123, "score": 95.5} - 验证是否生效：发请求后看 Headers → 自动带
Content-Type: application/json；若没出现，说明没选对模式
后端接收不到数字？检查 Jackson/FastJSON 的反序列化配置
Postman 发得再准，后端解析出错也会让数字“消失”或变成默认值。常见原因：
- 字段声明为
Integer但 JSON 里是0或null→ 检查是否用了@JsonInclude(JsonInclude.Include.NON_NULL)导致字段被跳过 - FastJSON 默认不开启
SupportSmartMatch，遇到"123"（字符串）无法自动转成int→ 需显式配置或改用 Jackson - Spring Boot 2.6+ 默认禁用
ALLOW_COERCION_OF_SCALARS，导致"123"无法转int→ 若必须兼容字符串数字，需在application.yml加：spring: jackson: deserialization: coercion-of-scalars: true
大整数（如 19 位 ID）在 JS 环境里可能丢失精度
Postman 前端基于 Chromium，JSON 解析走 V8 引擎。虽然发送时是原始文本，但如果你在 Tests 脚本里用 pm.response.json().id 取值再做断言，超 2^53 的整数可能被 JS 自动转成科学计数法或截断。
- 例如：响应中
{"order_id": 1234567890123456789}，在 Tests 里pm.response.json().order_id === 1234567890123456789可能返回 false - 安全做法：用字符串方式取值：
pm.response.text()+ 正则或 JSON.parse 配合 reviver 函数处理大数 - 或者直接断言字符串：
pm.expect(pm.response.text()).to.include('"order_id":"1234567890123456789"')
真正麻烦的从来不是怎么填数字，而是前后端对「数字类型」的隐含假设不一致——比如前端认为 0 和 "0" 等价，后端却严格区分。填对 JSON 格式只是第一步，得连着后端日志一起看，才能确认那个 123 到底是以什么形态抵达的。
