手动递归比json.stringify更高效：前者支持早停、无序列化开销、复杂度o(n)，后者需全量字符串化并扫描，内存与时间成本高。
处理“深度极小、广度极大”的 JSON 对象时，性能差异主要不在于“深”或“浅”，而在于遍历方式与内存访问模式是否匹配数据结构特征。“JSON 方法”通常指 JSON.stringify 后字符串比对，而“手动递归”指逐字段、按需比较的原生对象遍历逻辑。二者在该类场景下表现截然不同。
字符串化比对（JSON 方法）会显著放大开销
对广度极大的对象（例如含数千个同级键的顶层对象），JSON.stringify 必须一次性构建完整字符串：
- 触发全量序列化，包括所有键名重复拼接、引号转义、空格缩进（即使未启用格式化，内部仍需状态管理）
- 生成的字符串可能达 MB 级，仅内存分配与拷贝就成为瓶颈
- 后续字符串比对（如
===或 diff 工具）仍需扫描整个长串，无法提前终止
手动递归能实现“早停”和局部跳过
针对广度大但深度浅的结构，手动递归可自然利用对象属性枚举的局部性：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 用
for...in或Object.keys()遍历顶层键，发现第一个差异即可返回，无需看后续 999 个字段 - 每个字段值若为基本类型（string/number/boolean），直接用
Object.is()判断，无序列化成本 - 若某字段是嵌套对象，才进入下一层——而“深度极小”意味着几乎不会递归，实际就是一次扁平循环
键顺序敏感性决定是否需要预处理
广度大的对象常因键序不一致导致误判，但这不是递归本身的问题，而是比对策略问题：
- 若业务允许忽略键序（如配置项集合），手动递归可先统一提取键名排序再比对，开销远低于全量 stringify
- 若必须保持原始键序语义（如 API 响应字段顺序有契约），则需确保两个对象键序一致，或改用路径映射法（如将
{a:1,b:2}转为{"$.a":1,"$.b":2}再比对 Map）
实际建议：用轻量递归 + 早期退出 + 可选排序
不必在“用库”和“全手写”间二选一。可直接采用知识库中提供的零依赖 diff 函数，并稍作适配：
- 对广度极大对象，它只做单层 for-in + Object.is，复杂度 ≈ O(n)，n 是顶层键数量
- 删除标记（
"deleted"）逻辑天然支持“只看 cur 有、old 没有”的增量场景 - 如需稳定输出，可在调用前对 old/cur 的顶层键做
Object.keys().sort()，再传入 diff —— 排序成本仍是 O(n log n)，远优于 O(n × avg_value_length) 的 stringify
