JSON 转 CSV：选择如何展开嵌套对象

处理前的准备

先定义一行的含义和每列的规则

转换数据前，先明确一行表示一笔订单、一个产品，还是同一产品的一项选项。记录单位不同，合并和去重的依据也不同。结果用于另一个系统导入，还是给人阅读的报表，也会影响列名和顺序。格式变化不会补出缺失值或业务规则，应拿真实导入模板核对必填项。不能只因两行名称相同就认定重复，也不能只用行数衡量内容完整。先把应该保留的记录和需要展示的字段确定下来，再选择相应处理。

读取表格时先选对标题行和工作表。说明行被当成数据时，整份文件的列名和记录数量都可能错位。同义列的拼写和前后空格不同，可能产生额外列，应在原文件中统一。CSV还需要确认编码、分隔符及引号内的换行。文字乱码时先检查解码方式，不要直接覆盖成猜测的值。对于公式列，要了解工具读取的是文件中已保存的计算结果，还是实际有其他支持；不要假定导入一定会重新计算源工作簿。

产品代码和长标识符要与计算数字区别。需要保留前导零或最后几位时，先看源文件中的字符是否还在。已经丢失的零、截短的编号不能靠转换推测恢复。日期的月日顺序、小数点和千位分组也需要原始规则。混合规则的数据应先分开，不要对整列套一个解释后默认全部正确。未能解释的记录留在报告中，逐个检查其原意；看起来像数字的值，未必可以当金额相加，含编号的字段也未必适合排序成数值顺序。

比较或连接时，选择能区分记录的实际键，并确认旧新文件或主表参照表的顺序。忽略空格与大小写可能把不同代码合并，因此要按代码规则决定。去重前比较同键记录的金额和状态，再选保留首条或末条。参照表同键重复可能阻止连接；多值展开又会复制其他列，使同一金额出现在多个结果行中。汇总前必须理解记录为什么增加，不能把每个新增行都当成新的交易。留有原始行位置的报告有助于追查。

用原始行和报告解释结果的变化

处理后应能说明行数增加或减少的原因。合并检查各文件的记录数和来源，拆分检查空值形成的组，映射则检查每列值是否去了正确位置。JSON的嵌套结构与平面表能表达的内容不同，应挑字符串、空值和数组的实际记录查看。列名一样、显示相近，并不能证明类型和结构没有变化。输入中需要的层级若无法由目标表表示，必须按目标用途判断如何使用结果，不能把生成成功当作结构完全保留的证明。

验证或去重报告提供源行号时，应回到那个位置看具体值。没有错误只针对已提交的规则，不代表所有业务条件都成立。分组总和或平均值可以选一整组与原件核算，同时确认计数选项数的是什么。计算列出现货币符号或文字，应在理解含义后清理。缺失值报告若不自动补值，就把它当检查依据，不要期待结果中已补齐。记录所用规则和人工确认的范围，能避免下次把一份有限检查报告误当成通用保证。

用于打印的表、尺寸图和代码标签，要同时核对显示值与实物尺寸。不能假定这些输出会换算单位或签发新产品代码。QR、条码生成后，将名称和编码逐项对应，并按使用尺寸打印扫描。处理编码或Base64时也要区分文字编码与字节表示：可逆的编码不是加密，输出字符串不等于压缩后的内容。XML与JSON等模型不同的格式，需检查字段与结构表达，而不是只看后缀是否改变；后续系统需要什么应先确认。

下载后在真正使用的软件中重新导入。查看CSV中的标识符是否被改为数值或日期，以及公式结果是否与源程序保存的值一致。乱码已写入原件、长数字已截断或列根本不存在时，重复执行不会补回事实。失败时先读错误指出的列和规则，区分源数据问题与设置问题。把未解决行和已确认值一起保留，便于下次追踪修改范围。对导入模板的顺序、必填和类型还应按接收系统核对，不能只以当前导出文件能打开作为验收标准。