部署包里日志按天拆，我拿文件头排序才发现顺序全乱了

上周排查一个线上问题，需要按时间线 grep 三天的日志。日志包是运维用 Win解压缩 批量打的，解压速度确实快，200多MB的包几秒钟就出来了，这点得认。

问题是解压出来的文件名是 app-20240611.log.1、app-20240611.log.2 这种，按文件名排序后 log.10 会排在 log.2 前面。我当时没细看，直接 cat *.log.* 拼起来 grep，结果时间线全是乱的，关键的那条异常夹在中间，差点漏掉。

后来我做了个小实验，用三台机器（Win10、Win11、一台Server 2019）分别用 Win解压缩（v3.2）、7-Zip（v23.01）、Bandizip（v4.0）解压同一个分卷包，结果：

• Win解压缩：解压速度最快，平均 8.3 秒，但解压后不带任何目录结构信息，分卷合并后文件名顺序按打包顺序来，不按时间。
• 7-Zip：平均 11.7 秒，慢一点，但 7z l 能直接列出包内文件的原始时间戳，我拿这个对账才发现打包时顺序就错了。
• Bandizip：速度居中，但有个选项可以按修改时间解压，比较省心。

我的结论： 如果只是普通用户解压个文档、照片，Win解压缩的速度优势是实打实的。但像我这种要按时间线处理日志的，命令行支持太重要了。7-Zip 慢那几秒，换来的是 7z l 和 -t 参数能提前发现顺序问题，值。

现在我改了个笨办法：解压前先用 7-Zip 列一遍包内结构，确认时间戳顺序，再决定解压后怎么命名。多花两分钟，省一晚上。

顺便问一句，你们处理多天日志包时，是直接按文件名排序，还是有什么更靠谱的排序依据？