JSON序列化与反序列化：从底层原理到安全深拷贝的工程实践

1. 先搞懂一个扎心的事实：JSON序列化不是“把对象变成字符串”那么简单

做前端这几年，我最怕听到一句话：“JSON嘛，就是JSON.stringify和JSON.parse两个函数，背下来就行了。”每次听到我都想叹气。真要是这么简单，就不会有那么多线上事故是因为“后端返回的字段丢了”或者“明明同一个对象，存进缓存再拿出来就变了”这种问题了。

先看一个最典型的场景：前后端联调。前端拿到后端接口返回的数据，本质上是一个JSON字符串，浏览器帮你做了一层解析，你才能用data.list这种方式访问。反过来，你把一个对象通过fetch发送给后端，JSON.stringify帮你把它变成字符串。这整个过程，就叫JSON序列化和反序列化。序列化就是把内存中的对象结构转成可以传输、可以存储的文本格式；反序列化就是把文本格式还原成内存中的对象结构。

但问题在于，这个“转”的过程不是无损的。它不是复印机，而是翻译官。翻译官会丢掉原文里那些不符合目标语言习惯的东西。如果不知道它丢掉什么、保留什么、为什么这样设计，你迟早会在某个深夜被一个“数据怎么莫名其妙变了”的Bug折磨。

这篇内容适合谁？适合那些已经会用JSON.stringify和JSON.parse，但从来没认真看过它们行为边界的初级和中级开发者，也适合正在做前后端联调、缓存设计、数据上报、配置管理的全栈工程师。我会把序列化和反序列化的底层行为、定制方案、安全红线、深拷贝适用边界以及性能问题都过一遍，尽量让这些知识点连成一张网。

2. JSON.stringify的序列化规则：哪些值被保留，哪些值被静默丢弃

2.1 基础类型确实好办，但别有侥幸心理

先说最顺利的情况。数字、字符串、布尔值、数组、普通对象，这些规则你大概率已经背下来了：

javascript复制const source = {
  name: '张三',
  age: 28,
  isAdmin: true,
  scores: [90, 85, 92],
  address: {
    city: '杭州',
    district: '西湖区'
  }
};

console.log(JSON.stringify(source));
// {"name":"张三","age":28,"isAdmin":true,"scores":[90,85,92],"address":{"city":"杭州","district":"西湖区"}}

这段代码看起来平平无奇，但背后有几个容易被忽略的点。比如对象属性的顺序，JSON.stringify会按照对象属性定义时的顺序输出，但这个“顺序”有一个前提：它只保证字符串键的枚举顺序遵循对象的[[OwnPropertyKeys]]规则。数字键会先被排到前面，而且按升序排列，字符串键按照插入顺序排列。所以如果你有个对象叫obj，它的键是{ b: 1, 2: 'two', a: 3, 1: 'one' }，序列化出来的顺序会是{"1":"one","2":"two","b":1,"a":3}，因为数字键优先。这个坑在接口签名校验或者某些需要固定字段顺序的场景里会咬你一口。

再说基本类型本身。JSON.stringify接收一个普通字符串会返回一个带引号的字符串，比如JSON.stringify('hello')返回的是"\"hello\""，这里的两层引号经常让人困惑。第一层是JSON语法要求的双引号，第二层是你在控制台看输出时看到的转义表示。实际上存储和传输时，字符串值必须用双引号包裹，单引号不属于JSON语法。很多从Python或者PHP转过来的同学容易在这一步栽跟头，因为那些语言的序列化工具对单双引号没那么苛刻，但JS的JSON序列化严格按照规范来。

2.2 undefined、函数、Symbol、NaN：被“吃掉”的幕后黑手

接下来是重头戏。这几种类型在序列化时会以不同方式被丢弃或转换，规则如下表：

这个表值得记住。我见过一个真实的生产事故：后端要求前端上报一个埋点字段deviceId，但用户在未登录状态下这个字段恰好是undefined，前端直接JSON.stringify把整个对象发过去了，后端因为拿不到deviceId直接把整条数据判为无效。排查半天发现不是网络问题，就是JSON.stringify把undefined属性静默丢弃了。很多人以为“少了字段”是后端没返回，没想到是前端序列化时丢的。

数组里则完全是另一套逻辑。undefined和函数在数组里会变成null，这意味着数组的长度和索引位置会被保留。举个直观的例子：

javascript复制const arr = [1, undefined, function() {}, 4];
JSON.stringify(arr);
// "[1,null,null,4]"

所以如果你的数组里含有稀疏项或函数项，序列化后你再拿arr[1]去判断是否为undefined，会发现它变成了null，逻辑就变了。这种“位次保留但值被替换”的行为，在传输上下文信息时很容易造成意想不到的副作用。

NaN和Infinity会被转换成null，这一点对于数学计算类的数据上报是个大坑。比如你有个监测系统在统计页面首屏加载耗时的P95值，某些异常情况下算出来是Infinity，序列化后直接变成了null。如果后端不做校验，null可能会被当成0参与聚合，整个指标就被污染了。所以涉及数值型数据上报时，一定要在序列化前做一次显式的数值清洗。

2.3 循环引用的报错：为什么JSON不能处理环形结构

还有一个让无数人崩溃的场景，就是循环引用。你先别觉得“正常业务哪来的循环引用”，用过Vue、React状态管理、图数据结构、链表结构的人都知道，环形结构在内存中太常见了。比如：

javascript复制const obj = { name: 'node1' };
obj.self = obj;

JSON.stringify(obj);
// Uncaught TypeError: Converting circular structure to JSON

报错的原因是JSON格式本质上是树状结构，没有指针概念，无法表达“某个节点指向自身”。规范规定，一旦检测到循环引用，就抛TypeError。这个报错不会告诉你具体是哪条链路导致了循环，它只说“检测到循环结构”，所以排查起来比较烦。

在实际项目中，我见过很多人为了绕开循环引用，暴力地手动删除可疑字段。这可能行得通，但很脆弱。更稳妥的做法是：要么在序列化前用replacer函数做定向裁剪（下一章会详细讲），要么准备一个基于WeakMap的循环引用检测工具，序列化前先跑一遍，把所有环的位置打印出来，方便定位。我自己的习惯是，如果数据结构复杂到可能环引用，宁愿自己写一个安全的序列化函数，也不要裸用JSON.stringify。

3. 用replacer和toJSON定制序列化输出，告别“字段泄漏”和“无关数据”

3.1 replacer函数的工作原理

JSON.stringify的第二个参数replacer，很多人在刷面试题时见过，但工作中用得不多。它的作用是在序列化过程中拦截每一次“键-值”对的处理，让你有机会改值、删键、换名。

replacer可以是一个数组，也可以是一个函数。数组形式很简单，就是白名单：

javascript复制const user = {
  id: 1,
  name: '李四',
  phone: '13800000000',
  password: 'abc123',
  email: 'lis@example.com'
};

JSON.stringify(user, ['id', 'name']);
// {"id":1,"name":"李四"}

这种用法在做接口字段裁剪时特别有用，比如后端只需要id和name，你就不用再手写一个“只取这两个字段”的新对象了。但白名单数组有一个局限：它只对对象属性生效，不会处理数组元素。另外，如果你的对象嵌套层级很深，白名单也是对所有层级的属性生效的，这可能导致你误删了深层嵌套里想要保留的字段。

replacer函数则更灵活，它的签名是(key, value)，返回值会替换原始值。注意，第一次调用时key是空字符串，value是你要序列化的整个对象。所以代码里通常要先判断if (key === '') return value;，否则你会在第一层就把整个对象搞丢。

javascript复制const user = {
  id: 1,
  name: '李四',
  phone: '13800000000',
  password: 'abc123',
  email: 'lis@example.com'
};

JSON.stringify(user, (key, value) => {
  if (key === '') return value;
  if (key === 'password') return undefined; // 删除敏感字段
  if (key === 'phone') return value.replace(/^(\d{3})\d{4}(\d{4})$/, '$1****$2'); // 手机号脱敏
  return value;
});
// {"id":1,"name":"李四","phone":"138****0000","email":"lis@example.com"}

这个例子里最关键的一点是：replacer返回undefined时，整个属性会被删除。利用这一点，你可以做精确的敏感字段过滤。而且这个过滤是发生在序列化过程中，不污染原始对象，比手写循环拷贝干净多了。

3.2 toJSON：在源头控制对象的序列化结果

如果说replacer是从外部干预序列化，那toJSON就是从内部给对象一个“自定义序列化钩子”。规范规定，JSON.stringify在序列化一个对象时，会先检查这个对象上有没有toJSON方法。如果有，就调用它，然后序列化toJSON的返回值，而不是序列化对象本身。

这个机制在日期对象上表现得最明显。Date.prototype上内置了toJSON方法，它返回的是toISOString()的结果，所以：

javascript复制JSON.stringify({ createdAt: new Date() });
// {"createdAt":"2025-06-01T12:34:56.789Z"}

如果你不想要ISO格式，想统一输出时间戳或者自定义格式，给对象定义toJSON是更优雅的做法：

javascript复制const task = {
  title: '完成年报',
  deadline: new Date('2025-12-31T23:59:59'),
  toJSON() {
    return {
      title: this.title,
      deadline: this.deadline.getTime() // 输出时间戳
    };
  }
};

JSON.stringify(task);
// {"title":"完成年报","deadline":1767196799000}

这里有个细节很多人没注意到：toJSON的返回值会继续参与后续的序列化流程，也就是说如果返回值本身还有嵌套对象，嵌套对象如果也有toJSON，会继续调用。这个链式过程给了你极强的控制力。我在封装日志系统时，就让Logger对象实现了toJSON，把内部一堆临时状态全部过滤掉，只输出一行关键的告警摘要。这样不管日志库内部结构多复杂，序列化出去永远干净。

3.3 space参数：格式化输出不是只能用于调试

JSON.stringify的第三个参数space，大多数人只在调试时用过。但它在配置文件生成、日志美化、人工审阅的场景里价值很高。它可以是一个数字，表示缩进空格数，也可以是一个字符串，用于自定义缩进符号。

javascript复制JSON.stringify({ name: '王五', tags: ['a', 'b'] }, null, 2);
// {
//   "name": "王五",
//   "tags": [
//     "a",
//     "b"
//   ]
// }

有个容易被忽略的点是：space为数字时，最大只能到10，超过10按10处理；space为字符串时，最多取前10个字符。这个限制是规范写死的，目的可能是防止恶意生成超大缩进把存储空间打爆。我在生成一些给人看的配置文件时，会故意用'\t'作为space，让文件里全是Tab缩进，和团队既有风格保持一致。

4. JSON.parse的容错处理与reviver的逆向魔法

4.1 解析失败的三个高频原因与应对姿势

反序列化最烦的就是解析失败。JSON.parse是严格模式，稍微不合规就会直接抛SyntaxError，而且不给你任何修复机会。常见失败原因有三类。

第一类是单引号。JSON的字符串值必须用双引号包裹，但很多人手工写数据时习惯用单引号：

javascript复制JSON.parse("{'name': '赵六'}");
// Uncaught SyntaxError: Unexpected token ' in JSON

严格来说这是“犯法”的，但你也拦不住配置文件里出现这种写法。我的建议是：如果是自己可控的数据源，直接改成双引号；如果不可控，要么用try/catch包起来做兜底，要么上一些宽松解析库。不过谨慎起见，我一般不推荐为了迁就脏数据去引入宽松解析，因为宽松解析还会带来安全问题（后面讲）。

第二类是尾逗号。JSON语法不允许对象或数组最后一个元素后面加逗号。但手写的时候很多人习惯性地加上，然后JSON.parse就罢工了。这个错误提示比较隐晦，往往只说“Unexpected token }”，你盯着看半天不一定能发现是尾逗号。

第三类是undefined和NaN。你没法直接JSON.parse('undefined')或JSON.parse('NaN')，它们不是合法的JSON值。这个坑在对JSON.stringify的结果做反向操作时不存在，因为序列化不会产出这些词；但你解析从别的程序或别的语言传来的数据时，可能会碰到。

最稳妥的容错方式是这样的：

javascript复制function safeParse(str, fallback = null) {
  try {
    return JSON.parse(str);
  } catch (e) {
    console.warn('[safeParse] parse failed, fallback used.', e);
    return fallback;
  }
}

注意，fallback的选择也很关键。如果解析的是列表，fallback最好是[]而不是null，这样下游用list.map()时不会直接报错。如果解析的是对象，fallback最好是{}。这种“面向下游容错”的经验，能帮你少写很多防御性判断。

4.2 reviver：把普通对象还原成你想要的形态

JSON.parse的第二个参数reviver，是replacer的镜像操作。它会在这个递归解析过程的末尾从里向外调用，你可以趁机篡改值，或者把普通对象“升级”成类的实例。

假设你有一个User类：

javascript复制class User {
  constructor(id, name) {
    this.id = id;
    this.name = name;
  }

  greet() {
    return `你好，我是${this.name}`;
  }
}

你从后端拿到的JSON只是一个普通对象，没有greet方法。你可以在reviver里做一次“还原”：

javascript复制const jsonText = '{"id":1,"name":"小明"}';
const user = JSON.parse(jsonText, (key, value) => {
  if (key === '' ) return value;
  if (value && typeof value === 'object' && 'id' in value && 'name' in value) {
    return new User(value.id, value.name);
  }
  return value;
});

user.greet(); // 你好，我是小明

这种模式在做DTO（数据传输对象）还原时特别有用。不过要提醒一句：reviver的执行顺序是从最内层开始向外层的，也就是说如果对象嵌套了多层，内层的值会先经过一次reviver，外层再经过一次。如果你的reviver对某一层做了类型转换为类实例，外层再拿到这个类实例时，它已经带有原型方法了。如果你依赖这个顺序，可能会踩到一些微妙的问题。所以尽量把reviver的逻辑写得幂等，也就是不管跑几遍，结果都稳定。

4.3 JSON.parse处理大数字时的精度陷阱

这个坑我碰到过不止一次。JSON.parse遵循JavaScript的数字格式，数字统一按双精度浮点数存储。当你解析一个超过Number.MAX_SAFE_INTEGER（即9007199254740991）的整数时，精度就丢了。

javascript复制const bigId = '{"id": 9007199254740993}';
JSON.parse(bigId).id;
// 9007199254740992，最后一位变了

在社交平台、订单系统、支付系统里，后端下发的订单号或雪花ID往往超过16位，前端直接解析再传给其他地方，就可能发生“最后一位变了”的惨剧。解决方案要么让后端把大整数转成字符串返回，要么在前端解析时对特定字段做特殊处理——检测到超过安全范围的数字时，用字符串的方式保留原始值。但JSON.parse本身不支持“大整数模式”，需要你换用json-bigint这类库来解析。需要特别强调的是，这不是JSON.parse的Bug，而是JavaScript数值存储的设计限制。理解了这一点，你才能在架构设计时提前规避。

5. 反序列化安全：eval绝对不能用来解析JSON，其他语言的反序列化漏洞也正在步步紧逼

5.1 为什么eval是洪水猛兽

网上可能有人教过你用eval解析JSON，理由是“能直接执行表达式”或者“比JSON.parse更宽容”。如果你现在还这么做，请立刻停手。eval的设计目的是执行任意JavaScript代码，而不是解析数据。当你把一段不可信的字符串交给eval时，等于把整台浏览器或Node进程的控制权交给了攻击者。

举个最简单的例子：

javascript复制const data = '{"name": "小明"}';
const obj = eval('(' + data + ')'); // 看起来能跑

那如果data变成这样呢：

javascript复制const data = '{"name": "小明"}); alert(document.cookie);//';

加上括号和注释之后，eval不再只是解析数据，而是在你的页面上执行了额外的代码。这种攻击统称为“反序列化攻击”——恶意数据被反序列化时触发了非预期的代码执行。前端场景里，JSON.parse本身是安全的，因为它只做语法解析，不执行任何代码；但一旦你用了eval、new Function，或者某些“增强版JSON解析库”，攻击面就打开了。

5.2 JavaScript与Python pickle、PHP unserialize、Java fastjson的类比

反序列化攻击不只是JavaScript的课题。Java生态里的fastjson、Python的pickle、PHP的unserialize、Ruby的Marshal.load，都遇到过因为反序列化不可信数据导致的远程代码执行漏洞。它们的共同点是：反序列化过程不只是恢复数据，还可能恢复对象、触发构造函数或__wakeup/readObject之类的魔法方法。当这些魔法方法可以被攻击者精心构造的输入触发时，漏洞就出现了。

JavaScript的JSON.parse之所以相对安全，是因为JSON不携带对象原型、不触发构造函数、不执行任何代码。它只是把文本映射为普通对象。所以从设计上讲，JSON本身就是一种“低风险”的序列化格式。但低风险不等于零风险，你要是把JSON文本丢给eval处理，相当于手动把低风险格式升级成了高风险通道。

我在安全审计时见过一个真实案例：某个内部工具从URL参数读取配置，然后用new Function('return ' + config)解析，结果被人在参数里塞了一段读取环境变量的代码。这里我强调一次：任何来源不可信的数据，都不应该用eval、new Function或者类似的动态执行方式去解析。需要更灵活的解析时，优先考虑JSON.parse配合reviver，因为reviver是受控的，它不会执行字符串里的代码，只会执行你自己写的逻辑。

5.3 处理不可信JSON的规范姿势

在处理前端获取到的JSON字符串时，我会遵守几条硬性规范：第一，只用JSON.parse，不用eval和new Function。第二，解析后不直接信任数据形状，至少用一层简单的字段存在性校验。第三，如果数据可能来自跨域或第三方脚本，建议在解析前做一个大小限制，防止超大JSON造成内存耗尽。第四，尽量不要把解析后的数据直接拼接到innerHTML或document.write里，因为JSON值里可能藏着<img onerror=...>这种载荷，一旦被当成HTML解析就会触发XSS。

关于反序列化漏洞，社区里有一个通行的原则：不要反序列化不信任的数据；如果必须要反序列化，就选一个安全的格式和安全的API。JSON在JavaScript里正好是那个安全选项，前提是你不主动破坏它。

6. 用JSON做深拷贝：人人都说行，但坑起来也真要命

6.1 为什么说JSON.parse(JSON.stringify(obj))是“乞丐版深拷贝”

一聊到深拷贝，老程序员们就会露出会心的微笑，然后甩给你一行代码：

javascript复制const cloned = JSON.parse(JSON.stringify(obj));

这行代码确实是深拷贝，绝大多数业务场景里也够用。但它不是万能的。因为序列化过程会丢失那些被JSON格式“不支持”的值，所以深拷贝出来的对象和原始对象之间，会有很多隐形差异。

最典型的差异是：undefined、函数、Symbol会丢失。如果你拷贝的对象里有一个方法，拷贝结果里这个方法直接消失。你用这个“拷贝版”去调用原本的方法，会得到TypeError: cloned.draw is not a function。第二个差异是Date对象会被转换成字符串，拷贝出来不再具备getTime之类的方法。第三个差异是RegExp、Map、Set、WeakMap、WeakSet会被转成空对象或空数组，根本保留不了原本的结构。

6.2 那些丢失原型和特殊类型的典型场景

举一个“踩过雷”的具体例子。状态管理库里经常有这样的结构：

javascript复制const state = {
  user: {
    name: '小红',
    tags: new Set(['vip', 'active'])
  },
  cachedAt: new Date(),
  log: function(msg) {
    console.log(msg);
  }
};

const snapshot = JSON.parse(JSON.stringify(state));
// snapshot.user.tags 变成了 {}
// snapshot.cachedAt 变成了 "2025-06-01T12:34:56.789Z"
// snapshot.log 消失了

如果你接下来的逻辑要遍历tags并调用has方法，这里直接就会崩溃。因为Set在序列化时没有任何内置的toJSON方法，它被当成普通对象序列化，而普通对象的键是这个Set实例内部的一些不可枚举属性，所以序列化结果往往是{}。

这种问题最简单的规避方法：在设计数据结构时，就不要把Date、Map、Set、RegExp等特殊对象嵌套在需要深拷贝的对象里。如果必须嵌套，那就得用更全面的深拷贝方案，不是靠JSON一行搞定。

6.3 structuredClone：浏览器原生支持的深拷贝替代方案

其实现代浏览器和Node 17以上已经提供structuredClone这个全局函数。它可以处理Date、Map、Set、RegExp、ArrayBuffer、TypedArray等各种结构化类型，也能正确保留原型链上的继承关系。

javascript复制const original = {
  name: '小刚',
  tags: new Set(['a', 'b']),
  createdAt: new Date()
};

const cloned = structuredClone(original);
console.log(cloned.tags instanceof Set);    // true
console.log(cloned.createdAt instanceof Date); // true

structuredClone也不是万能的。它不能克隆函数，也不能克隆Symbol，遇到循环引用会报DataCloneError。但它处理日常的深拷贝需求，比JSON方案强太多了。如果你还在用JSON.parse(JSON.stringify())做表单数据深拷贝，我建议你立即换成structuredClone。不过在换之前先确认一下目标环境是否支持，比如某些低版本WebView里就没有这个函数。你可以写个兼容判断：

javascript复制const cloneDeep = (value) => {
  if (typeof structuredClone === 'function') {
    return structuredClone(value);
  }
  return JSON.parse(JSON.stringify(value));
};

这种兼容写法最稳妥。实际项目中，我在遇到“需要深拷贝且对象里只有基础类型和普通嵌套对象”的时候还是会用JSON方案，毕竟代码短、性能好；但只要对象里混入了Date、Map、Set，我第一反应就是structuredClone。

7. 性能与边界：大数据量JSON序列化的实战参考

7.1 JSON.stringify和JSON.parse的性能基线

很多人担心JSON序列化和反序列化有性能问题，其实在绝大多数业务场景里，这个性能开销可以忽略不计。我自己在Node环境简单测试过：对一个包含1万条简单对象记录的数组做JSON.stringify，耗时大约在10毫秒到20毫秒之间；JSON.parse也差不多。这个量级在普通接口请求处理中完全够用。

但是如果数据量到了10万条、100万条，或者每条记录的字段特别深、嵌套特别多，性能就开始变得可观了。这时候有几个优化方向。第一，用replacer裁剪字段，减少序列化输出的体积，这能同时降低stringify和网络传输时间。第二，对高频调用的序列化场景，尽量复用同一个对象池，避免频繁创建临时对象导致GC压力。第三，如果是对超大JSON做解析，不要一次性JSON.parse到内存中，考虑用流式分析方法。

7.2 大数据量下的流式解析与序列化思路

Node里的stream模块可以配合JSON解析做成流式处理。社区里有一些现成方案，比如JSONStream、stream-json。以stream-json为例，它可以把JSON文本拆成一个个token，边读边处理，不需要把整个JSON对象一次加载进内存。这种模式适合处理几百MB的JSON文件，比如日志分析、离线数据导入。

序列化方向也有流式方案，比如用Transform流逐块输出JSON。但说实话，这种需求在日常业务里不多，除非你在做视频转码、大数据导出之类的重活。普通Web应用里，把响应体控制在合理范围，然后用原生的JSON.stringify就足够了。不要过度设计。

7.3 循环引用的序列化兜底方案

如果你确实需要序列化一个可能包含循环引用的对象，又不能手动清字段，可以考虑用replacer加WeakMap来追踪已经访问过的对象。遇到重复对象时，可以用特殊的占位符代替，或者直接跳过。这个思路可以防崩溃：

javascript复制function createSafeStringify() {
  const seen = new WeakSet();
  return function(key, value) {
    if (typeof value === 'object' && value !== null) {
      if (seen.has(value)) {
        return '[Circular]';
      }
      seen.add(value);
    }
    return value;
  };
}

const obj = { name: '循环测试' };
obj.self = obj;

JSON.stringify(obj, createSafeStringify());
// {"name":"循环测试","self":"[Circular]"}

这个方法在排查问题时非常有用，即使不能表示循环关系，至少能让你看到“这里有循环”，而且不会抛错。我在调试状态管理、图数据可视化场景时不止一次用过它。

7.4 序列化与反序列化的一些个人经验总结

从实操里摸爬滚打这些年，我总结出几个针对JSON的固定习惯。第一，所有从外部传入的JSON一律用safeParse包一层，绝对不在裸奔状态下JSON.parse。第二，所有对外发送的数据，在JSON.stringify之前必须跑一次敏感字段过滤，用replacer也好，用表格白名单也好，反正不能把密码、token原样发出去。第三，设计接口时，后端能返回字符串的ID就不要返回数字ID，能返回时间戳就不要返回“2025-06-01 12:00:00”这种带时区歧义的格式，因为这些都会影响前端序列化和反序列化的契合力。第四，不要依赖JSON的字段顺序。虽然JSON.stringify对普通对象能保持插入顺序，但JSON格式本身不承诺顺序，后端拿过去解析也不应该依赖这个。

这些习惯让我在项目联调时少踩了很多坑。特别是字段顺序问题，有一次前端把对象重新赋值了几个键，序列化顺序变了，后端同学用位置解析数据，结果全乱套了。最后发现后端用的是一个不该用在JSON上的“位置敏感解析库”，换了按字段名解析就好了。这类问题本质上是序列化协议与解析协议不匹配，靠技术手段倒是能修，不如一开始就对齐规范。