先把问题解决
KitNelo的JSON转Excel把数字词法写成文本，包括数量和金额，以保留长编号、1.2300及1e3。本例输出orders两条数据、meta一条数据；若要计算，另用CSV转Excel保持id文本、仅将quantity设数字。null与空字符串都成为空单元格，不能据此还原原JSON。
可以亲自复算的示例
两份虚构门店 CSV，共 8 条记录。统一表头并清洗金额后：10 月 1–7 日合计 3,000，10 月 8–14 日合计 3,600，增长 20%。这组样例没有需要删除的重复记录。
压缩包内附字段映射、日期范围与预期合计。文件均为虚构数据，无需账号。
JSON允许的数字，不一定能被普通浮点数精确表示
RFC8259的数字说明讨论了实现精度的互操作边界；常见双精度实现能精确一致处理的整数范围有上限。编号属于标识时，原始系统使用字符串通常更清楚，已有文件仍应保留原始数字文本。
不要先用普通解析器读入、改变精度，再指望导出时补回末尾。这个入口使用保留数字原文的解析方式，但如果上游已经把编号改成9007199254740992，转换器无法知道原来是否应为9007199254740993。
完整输入：两行订单和一行批次来源
下载包包含orders.json、故意损坏的invalid-orders.json、只用于计算副本的quantity.csv，以及README和expected.json。以下是完整orders.json，均为编辑自编数据。直接保存原文，不先用普通数值解析再重新序列化，避免转换前已经改变长编号。
顶层orders和meta的值都是数组，因此这份结构对应两张工作表。meta只是本例批次说明，不是第三笔订单；不能把2+1说成三笔订单。
{"orders":[{"id":9007199254740993,"price":1.2300,"quantity":2,"tags":["red","new"],"note":null},{"id":9007199254740995,"price":1e3,"quantity":3,"tags":[],"note":""}],"meta":[{"batch":"PRECISION-28","source":"Fictional editorial exercise"}]}导入、处理、重开：检查两张表和实际单元格
打开Excel文档工具，选择“JSON转Excel”，导入orders.json并处理下载。重新打开实际XLSX，应有orders、meta两张表。orders为2条数据加表头，meta为1条数据加表头，meta的batch为PRECISION-28。当前入口用记录字段并集建列，缺失字段留空。
orders表按id、price、quantity、tags、note核对。编号和数字原文必须逐字符一致；查看单元格值或编辑栏并检查类型，不能只凭列宽显示判断精度。price与quantity均是文本，SUM不能被假定会把文本当计量值。
| 字段 | 第一行 | 第二行 | 验收 |
|---|---|---|---|
| id | 9007199254740993 | 9007199254740995 | 两格都为文本、尾数完全一致 |
| price | 1.2300 | 1e3 | 文本，保留原写法 |
| quantity | 2 | 3 | 文本，不是数字2与3 |
| tags | ["red","new"] | [] | 各自为一个文本单元格 |
| note | 空单元格 | 空单元格 | 不再区分null与空字符串 |
可运行的计算副本：只将quantity设为数字
JSON入口没有逐列类型选择。为了把计算步骤做完整，包内另给出quantity.csv，字段仅id、quantity，仍是同两条订单。在Excel文档工具选择“CSV转Excel”，导入该文件，保持第1列id为文本，仅把第2列quantity改为数字，再处理下载。
重开这个独立XLSX，应有2条数据：id仍为两个原始长编号字符串，quantity分别为数值2、3。在接收方表格软件中对B2:B3求和应为5；编辑验收同时复读了导出单元格类型和2+3结果。不要把价格1e3是否应转成1000的业务决定混入这个数量练习。
可做一次防错检查：把第1列id误设为数字，当前CSV导入应提示精度风险并阻止处理。恢复id为文本后再导出。若已有系统输出末尾被改的编号，应回到权威原件取值，不能从近似数猜回；CSV列类型指南解释其他类型的设置边界。
id,quantity
9007199254740993,2
9007199254740995,3保真与算术分别验收
把所有像数字的列都转成数字，只核对数量总计5，就认为编号也正确。
长编号逐字符保留文本；只把quantity变数字，核对两行及总计5。原JSON和文本工作簿仍保留。
恢复演练：格式损坏、数组与空值分别处理
invalid-orders.json故意在第二条quantity后多写一个逗号。导入并处理应报JSON格式错误；重新载入正确orders.json，再核对2条订单和1条meta。不要为了得到成功提示删除第二条订单，也不要把没有生成工作簿误判为零订单。
tags数组保留在一格，未展开为标签明细；空数组[]仍是文本。note的null和空字符串都输出空格，缺失字段也可能为空。expected.json记录了这一损失。若三种状态影响审核，在上游增加明确状态字段或采用能保留类型的流程，并保留原JSON。
多张工作表不自动建立关系、外键或一对多连接。需要展开嵌套结构时先设计主键与子表；CSV与JSON往返核对提供另一类结构检查，不能据此承诺本XLSX可以无损往返。
交付账本：两张保真表与独立计算副本
交付时同时保留orders.json、文本保真XLSX、quantity.csv及计算XLSX，写明每个文件的用途。顶层对象全部值为数组的本例映射为两张表；其他形状不会自动猜业务关系，表名还可能受Excel限制而被清理或截短。
本例编辑验收实际复读了下载XLSX的表名、行数、单元格值和类型，并在中英文工具中走过损坏输入及类型风险恢复。它不代表任意大JSON、接收方软件或所有嵌套结构都通过。处理消耗浏览器内存，大文件应先用代表性小样验证。
这份JSON交付须同时满足
- orders为2条数据，meta为1条数据；批次PRECISION-28不计入订单数。
- 两个长编号、1.2300及1e3原文保持；JSON路线quantity也是文本。
- 独立计算副本仅quantity为数字2、3，合计5，id仍为原文本。
- 损坏JSON先修复原文，记录数不靠删行减少。
- null/空字符串的区别已说明丢失；原JSON保留，未承诺无损往返。
用门店样例复算完整处理流程
下方样例补充一个跨工具交接练习：编号 0011 应保持文本，备注中的逗号和单元格内换行也应保留。流程内部通过 JSON 传递实际结果，不用 CSV 再推断编号类型；金额字段则经用户确认后转为数字。原始 CSV 直接用 Excel 打开可能丢失前导零，应使用文本/CSV 导入并将编号列设为文本。这组短编号样例不替代上文的长数字精度案例。
跨工具交接后分别验收数值与文本：金额按 2026 年 10 月 1–7 日、10 月 8–14 日求和应为 3,000 和 3,600；编号仍应为 0011 等原始文本，备注保留换行。20% 的变化率只验证金额计算，不能证明编号类型正确。请同时检查最终导出的文件，而不只看网页预览。
常见问题
导出后显示“数字存为文本”是不是失败？
在这条JSON转换路线中，这是保留数字原文的预期选择。是否转换为计算数值由字段含义决定，不能一键全表转换。
JSON里的日期会自动成为Excel日期吗？
不要假定会。JSON没有专门日期类型，日期通常是字符串；此入口不会根据外观自动确立时区或日期含义。
转换后再存JSON能保证完全还原吗？
不能。空值区别、对象键顺序、工作表名与嵌套表达都可能变化。保留原JSON，并把XLSX定义为阅读或处理副本。
参考资料与延伸阅读
按步骤开始处理
进入对应工具，预览处理结果，检查导出的文件。
