我发现了正则表达式的bug？（勤奋的懒惰模式）

记一次工作中发现的问题

我编写了一个程序，从ftp上下载对应的数据包来导入数据库。
匹配文件的时候，我使用了正则表达式来匹配文件

我先遍历出所有文件得到一个集合，再用逗号把文件名连接起来。
然后用正则在这个字符串里边匹配，就能判断是否有这个文件
因为文件名是由 文件名_(add|all)_日期_机构号 这样的格式组成的，所以我用正则来匹配。

然后，我的思路是 用 文件名add.?gz 用懒惰模式来匹配最短的符合条件的字符串就能拿到文件名了。

但是，程序却一直下不到文件，然后我把获取到的文件名打印出来，发现匹配的并不是最短的字符串

上图是我在工具里边测试正则的情况，阴影部分就是工具匹配的结果
开始我以为是工具的问题，后来我在网上的网站上匹配也好，文本编辑器的正则模式里边测试也好，无一例外，都是这个结果。

不禁让我怀疑起了正则表达式本身

把字符串和表达式发出来，感兴趣的同学可以自己测试一下

s_qnyp_t_cash_payment_add.*?gz

s_qnyp_t_bind_card_record_add_20210122_2750000.del.ok,s_qnyp_t_card_bin_record_all_20210122.ddl,s_qnyp_t_card_bin_record_all_20210122_0000000.del.gz,s_qnyp_t_card_bin_record_all_20210122_0000000.del.ok,s_qnyp_t_cash_payment_add_20210122.ddl,s_qnyp_t_cash_payment_add_20210122_2750000.del.gz,s_qnyp_t_cash_payment_add_20210122_2750000.del.ok,s_qnyp_t_cash_payment_process_add_20210122.ddl,s_qnyp_t_cash_payment_process_add_20210122_2750000.del.gz,s_qnyp_t_cash_payment_process_add_20210122_2750000.del.ok,s_qnyp_t_clear_record_add_20210122.ddl,s_qnyp_t_clear_record_add_20210122_2750000.del.gz,s_qnyp_t_clear_record_add_20210122_2750000.del.ok