这是JavaScript解析JSON时大整数精度丢失问题，因IEEE-754双精度限制，超Number.MAX_SAFE_INTEGER（9007199254740991）的整数会失真，需后端传字符串或Postman中用自定义JSON解析器保留字符串。
Postman里看到12345678901234567890变成1.2345678901234567e+19怎么办
这是 JavaScript 在解析 JSON 时对大整数的精度丢失问题，不是 Postman 的 bug，也不是后端返回错了。JSON 规范本身不区分整数和浮点数，所有数字都是 IEEE-754 double 类型，最大安全整数是 Number.MAX_SAFE_INTEGER（即 9007199254740991）。一旦超过这个值，JS 解析后就会失真。
常见现象包括：
- 后端明明返回
"12345678901234567890"（字符串形式），但在 Postman 响应体预览中显示为1.2345678901234567e+19 - 用
pm.response.json()取值后，id字段变成近似值，比如12345678901234567000 - 断言
pm.expect(json.id).to.equal("12345678901234567890")直接失败
用pm.response.text()手动解析 JSON，绕过 JS 数字自动转换
核心思路：不让 Postman 自动调用 JSON.parse()，而是自己控制解析过程，把大数字字段保留为原始字符串。
在 Tests 标签页写：
const raw = pm.response.text();
const json = JSON.parse(raw, (key, value) => {
// 把已知的大数字字段（如 id、orderNo）强制转成字符串
if (key === 'id' || key === 'orderNo' || key === 'customerId') {
return String(value);
}
return value;
});
// 现在 json.id 就是字符串 "12345678901234567890"
pm.test('id is correct string', () => {
pm.expect(json.id).to.equal('12345678901234567890');
});
注意点：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 必须提前知道哪些字段是大整数，硬编码进判断逻辑
- 不能依赖
typeof value === 'number'来识别——因为 JS 已经把它转成 number 并丢失精度了 - 如果字段名不固定（比如数组里的每个对象都有
id），需配合Array.isArray()和递归处理
后端改用字符串序列化BigDecimal或Long字段
更彻底的解法是让后端不传数字，直接传字符串。Java 项目常用以下方式：
- Fastjson：加注解
@JSONField(serializeUsing = ToStringSerializer.class)到字段上 - Jackson：用
@JsonSerialize(using = ToStringSerializer.class) - Spring Boot 全局配置：注册
MappingJackson2HttpMessageConverter，自定义ObjectMapper，对BigInteger/Long类型统一走字符串序列化
例如后端返回变成：
{
"id": "12345678901234567890",
"amount": "50.00"
}
这时 Postman 预览和 pm.response.json() 都能原样拿到字符串，无需脚本干预。
别信“切换 Postman 显示格式”这类误导方案
有人建议在 Postman 设置里关掉“Pretty”、切到 “Raw” 或 “Preview”，甚至用右键“Copy as curl”再粘贴回来——这些操作都无效。因为问题发生在 JSON 解析层，不是渲染层。
真正容易被忽略的是：即使你只做人工核对，也千万别直接看响应体右上角的“Pretty”视图里的数字值。它看起来像真实值，但底层 JS 已经把它转成 double 了。要确认，必须用 pm.response.text() 拿原始响应体，或者导出响应保存为 .json 文件用编辑器打开查原始字符串。
