一次浏览器崩溃问题的解决过程
在网盘类web应用开发中，我们的团队遇到了一个令人困惑的浏览器崩溃问题。某日，测试同学在一台Windows 11镜像的ECS机器上进行文件上传测试时，发现浏览器在访问特定网站后，过几秒自动崩溃。访问其他网站无此问题，且之前在类似环境下未出现此现象。
初步分析显示问题可能与操作系统Windows 11相关，测试同学发现浏览器内存使用异常增长至4GB时崩溃。一般情况下，浏览器能通过控制各个标签页的进程，避免因单个标签页问题导致整个浏览器崩溃。然而，当前情况却异常，访问特定网站时浏览器直接崩溃，且不涉及标签页控制逻辑。
通过查看任务管理器，我们发现了内存增长与崩溃的关键线索。问题似乎并非浏览器自身故障，而是与浏览器缓存相关。尝试在隐身模式下访问网站，问题消失，暗示问题可能源于缓存数据。清除浏览器缓存后，浏览器不再崩溃。
然而，问题在第二天复现，多次上传10GB文件后再次出现。这表明问题与缓存管理有关，但简单清除缓存不足以解决问题。深入分析后，我们注意到IndexedDB缓存文件大小异常增长，达到14GB。利用浏览器开发者工具检查IndexedDB缓存，发现其中记录了大量update操作。
通过进一步分析，我们怀疑是IndexedDB缓存文件记录了过于频繁的update操作，导致文件大小异常增长。这可能是由于业务代码在执行上传文件分片操作时，未能有效控制更新频次或优化数据存储结构，导致IndexedDB缓存文件持续增大，直至浏览器崩溃。
为了找到问题根源，我们对比了业务代码与官方文档，发现代码实现并无明显问题。进一步的分析指向了IndexedDB缓存文件大小与update操作频次及数据内容大小之间的关系。基于此，我们提出了两种解决方案：
减少update操作频次：通过节流技术限制update操作，避免在短时间内频繁执行。
优化数据存储结构：减少数据大小，优化update数据的存储方式，如简化key值、压缩数据结构。
我们实施了优化策略。方案一涉及对数据结构进行优化，包括简化对象数组、压缩数字和减少不必要的操作。方案二则通过创建专门的分片表来存储上传分片信息，减少对IndexedDB的更新压力。然而，方案二在实际应用中遇到了性能瓶颈，特别是在处理大量分片上传时，数据库插入速度跟不上上传速度，导致数据库更新延迟。
为了解决性能问题，我们进一步优化了方案二，将每个分片数据转换为独立的key，以减少数据库更新频次。同时，考虑到业务场景中的分片数量有限，我们确保了此方案的有效性。然而，在实现过程中，我们发现了IndexedDB中表的key数量似乎存在上限的问题，这导致了部分key的丢失。
为解决此问题，我们修改了表结构声明，删除了冗余索引，并回退了部分代码逻辑，以避免不必要的数据库操作。优化后的结果是MANIFEST-xxx文件的大小显著减少，问题基本得到解决。
多重随机标签