转换前先写清数据契约
先准备一个小型模拟固定样例，覆盖真实交换中的每种形态：必填与可选字段、null、空文本、布尔值、数字、日期、标识符、数组和嵌套对象。记录哪些字段是键、哪些可以缺失、哪些必须保留为文本。工具无法仅凭看起来像数字或日期的值推断业务含义。
同时定义目标格式。CSV 不是统一数据库格式；接收表格、批量加载器或合作方 API 决定分隔符、引号、换行、字符编码、表头和公式处理规则。JSON 语法更明确，但数值范围、重复名称处理和模式验证仍由具体实现决定。
解析时保护 JSON 语义
格式化或转换前先验证原始 JSON。格式化会重新序列化解析值，因此无意义空白会消失，长数字也可能已经被 JavaScript 数值模型舍入。若长账号是标识符，应在契约中把它定义为字符串。除非其他协议明确规定有序序列，否则不要依赖对象成员顺序。
嵌套数据需要明确的扁平化策略。把对象序列化到一个 CSV 单元格比静默丢弃结构更可靠，但下游必须知道该单元格包含 JSON 文本并可能需要二次解析。对于分析表，明确的规范化表或独立子文件通常比临时点号列名更容易验证。
把 CSV 当作方言与安全边界
带引号的 CSV 字段可以包含分隔符、引号和记录换行。应同时测试这三种情况，再加入空的末尾字段以及最后一条记录没有尾随换行的文件。确认导入器是否接受双引号转义，并核对空值、缺失值和带引号空字符串在加载后是否仍可区分。
表格应用可能把以公式标记开头的单元格当作公式。若不可信数据会被交互式打开，应定义公式注入处理策略，而不能假设 CSV 引号会禁用求值。还要用实际导入器验证字符编码和 BOM 预期；只使用可读英文样例无法发现非 ASCII 路径故障。
让数据交接可观察
记录源行数、目标行数、列集合和被拒绝记录。涉及交接责任时可为源文件计算校验摘要，但不要把非密码学文本指纹当作安全证明。保持原始导出不可变，后续发生转换缺陷时即可复现，而无需源系统重新生成已经变化的数据。
模式失败应指出记录和字段，但不要记录敏感值。应区分解析错误、模式错误和业务验证错误，因为它们的责任人和恢复动作不同。解析成功只表示语法被接受，不代表记录完整、已授权或有业务意义。
使用往返与金文件测试
实用回归集应包括一条简单记录、所有引号边界、Unicode、长标识符、null 与空值、异构对象键和嵌套结构。JSON 转 CSV 再转 JSON 后应比较语义值，而不是要求逐字节相同；同时把生成的 CSV 与已批准金文件比较，以保证列和引号行为稳定。
- 使用准确的生产导入器和导出器测试。
- 不用于算术的标识符应保留为文本。
- 每次交接都核对行数和拒绝记录。