接口返回只有一行，里面套着数组和对象。人工找一个型号已经费劲，若再把长订单号转成普通数字，可能在整理过程中引入原接口没有的错误。JSON工具应先帮助看清结构，再谈筛选和导表。
严格JSON和JavaScript对象，不是一种格式
将响应粘贴到XunL JSON格式化与在线解析，选择两格、四格或Tab缩进。若报错，先检查双引号、括号、逗号和是否夹入注释。标准JSON不接受单引号和尾随逗号，文档里的JavaScript示例不一定能原样解析。
不要为了消除错误全局替换所有引号，字符串里本身可能包含引号和转义。先保存原文，再按提示检查最小相关位置。更稳妥的方式是从接口原始响应复制，而不是复制带排版和注解的网页片段。
用一个产品数组理解字段路径
可以输入 {"products":[{"sku":"A-01","qty":2},{"sku":"B-02","qty":5}]}。格式化后先看products是数组，每项才是产品对象，再用JSON Pointer路径 /products/0/sku 定位第一条型号。数字零指第一个数组元素，不是SKU的一部分。
如果目标字段找不到，先看实际结构是否不同。例如响应把数据放在data下面，路径就需要包含这一层；某项为null时，也不能把它当作空对象继续展开。向开发报告问题时附路径与预期类型，会比只说“值不对”更明确。
大整数、空值和字符串，别随便互换
长ID应按接口约定保留，超出普通JavaScript安全整数范围的标识尤其适合作为字符串交换。工具支持大整数保留，并不代表后面接收它的表格或系统也会无损处理；每次跨工具仍需要抽查。
例如型号“0012”有前导零，转成数字十二就丢了信息。null、空字符串、零和字段缺失也可能代表不同业务状态，不能为了表格整齐统统替换成空白。语法合法只说明文本可解析，业务含义仍由接口定义决定。
导出CSV时，先定义“一行是什么”
比较两个版本时，缩进变化与业务变化应分别看。只重新排版，往往会使整段文本对比都出现改动；可以先用一致缩进整理两份资料，再检查具体字段差异。数组顺序若有业务含义，也不能为了对比方便随意排序，否则可能把优先级或时间顺序改掉。
需要表格分析时，检查嵌套展平选项与JSON Pointer列名。一个订单包含多项产品时，要明确目标是一行一个订单，还是一行一个产品，不应在展开以后把行数增加解释成订单数增加。
导出还可以按需要对公式样式文本加保护前缀，减少表格软件把文本当公式执行的风险。保留原JSON，与CSV抽查ID、数量和字段路径。下载成功不等于类型正确，尤其要检查日期、长数字与前导零。
输入不会作为代码运行，计算在浏览器本地进行；资料使用权限仍需自己判断。处理接口凭证、个人资料和客户记录前先脱敏，本地草稿保存也是独立选项，不要在共用设备无意留下完整响应。
解析成功，为什么接口还是拒绝请求？
接口可能还要求必填字段、特定枚举和业务条件。应结合接口文档与错误响应检查，格式化工具无法替你证明订单状态或权限条件成立。
结构很复杂，怎样让开发更快复现？
提供脱敏的最小有效JSON，保留相关层级、路径、实际值和预期值。缩小片段时不能删掉必要括号，否则会把业务问题变成新的语法问题。
个人微信：ssevening
