AWS Amplify Gen1 V6 文件上传恢复功能失效问题分析

在 AWS Amplify Gen1 V6 版本中，开发者报告了一个关于文件上传恢复功能失效的问题。本文将深入分析该问题的技术背景、原因以及解决方案。

问题现象

当使用 AWS Amplify 的 Storage 模块进行文件上传时，如果上传过程被意外中断（如浏览器刷新），再次尝试上传同一文件时，系统无法从上次中断的位置继续上传，而是会创建一个新的上传任务。这与预期的断点续传行为不符。

技术背景

AWS Amplify 的 Storage 模块提供了文件上传功能，并支持断点续传。其实现原理是：

1. 通过本地存储（localStorage）维护一个 __uploadInProgress 字典
2. 每个上传任务都会生成一个唯一的缓存键（cache key）
3. 当上传中断后，系统会根据缓存键查找并恢复上传进度

问题根源

经过分析，发现问题出在缓存键的生成逻辑上：

1. 缓存键由 getUploadsCacheKey() 函数生成
2. 该函数依赖 optionsHash 作为键的一部分
3. optionsHash 由 calculateContentCRC32() 计算得出
4. 每次调用 uploadData 时，即使上传同一文件，optionsHash 也会不同

这导致每次上传同一文件时，系统都会生成不同的缓存键，无法匹配到之前的上传进度记录。

解决方案

AWS Amplify 团队已在该问题的修复版本（v6.12.2）中解决了此问题。主要修复内容包括：

1. 修正了 optionsHash 的计算逻辑，确保相同文件上传时生成一致的哈希值
2. 优化了缓存键的生成策略，保证上传任务的可恢复性

验证结果

开发者确认在升级到 v6.12.2 版本后：

1. 文件上传恢复功能正常工作
2. 中断后重新上传同一文件时，能够正确从上次中断的位置继续
3. __uploadInProgress 中的记录显示正常

技术细节补充

值得注意的是，当上传多个不同文件时，如果上传选项相同，optionsHash 部分会保持一致。但这并不影响功能，因为缓存键的其他组成部分（如文件路径等）足以保证每个上传任务的唯一性。

总结

AWS Amplify 团队快速响应并修复了这个影响文件上传恢复功能的问题。开发者应及时升级到最新版本（v6.12.2 或更高）以获得稳定的文件上传体验。这个案例也提醒我们，在实现基于本地存储的状态恢复机制时，需要特别注意键值生成逻辑的一致性问题。