我使用了fineuploader s3，我刚刚发现了一个意想不到的（来自我的pov）行为。
我向客户提供上传文件的可能性
每件作品都有代码，例如12345_1298681和12345_84792782
让我们假设客户开始为两个订单上传文件（开始上传将工作设置为中断，因此在下一个上传者初始化它们被设置为_isResumable = true）
用户上传文件a.mov工作12345_1298681（s3键是12345_1298681 / a.mov）和b.mov到12345_84792782（s3Key是12345_84792782 / b.mov）
如果由于某种原因用户尝试上传a.mov工作12345_84792782 fineuploader将该文件识别为可重复使用，并在控制台中我可以看到
Identified file with ID 0 and name of a.mov as resumable.
Server requested UUID change from '60aecf65-67ca-4811-aa3c-6425620cc3f1' to 'a2bfc111-0c82-4e48-8512-a08c3e24cbd8'
但如果添加到工作12345_1298681，则a.mov可以恢复，如果添加到工作12345_84792782则不可。 我在文档中看到，如果我向onResume回调返回false，则文件从头开始重新启动，但问题是这个方法是删除文件的恢复数据而不是s3Key的恢复数据，这样我将失去在12345_1298681恢复上传的能力？
更清楚（希望如此）
我有
订单12345_123456 =＆gt; s3 key =＆gt; 12345_123456 / a.mov
订单12345_987654 =＆gt; s3 key =＆gt; 12345_987654 / a.mov
如果我开始上传订单12345_123456的文件而不是我停止它，如果我想在我的文件系统中使用相同的文件开始上传订单12345_987654，则fineuploader会识别该文件是相同的（这是正确的，但它的不同之处在于最后的密钥）并将其上传到12345_123456 / a.mov而不是12345_987654 / a.mov
这可能会导致一个问题：
我认为我上传一个订单的文件而不是我。
挖掘fineuploader的源代码我可以看到cookie id是由函数
生成的
来自qq.XhrUploadHandler的_getLocalStorageId
而不是
来自qq.s3.XhrUploadHandler的_getLocalStorageId但是在这些方法中都没有考虑到将文件与另一个文件区分开来的关键