StreamSaver.js项目中的浏览器缓存问题分析与解决方案

问题背景

在使用StreamSaver.js进行大文件下载时，开发者遇到了一个奇怪的缓存问题：在Chromium浏览器中，请求下载734MB的大文件时，有时会错误地返回仅1字节的内容。这个问题在Chrome和Firefox中并不存在，但在Chromium浏览器中频繁出现。

问题现象

当用户通过Chromium访问文件下载链接并点击下载时，网络调试工具显示：

1. 从Service Worker返回的响应头中，Content-Length正确显示为734103552字节
2. 但从实际存储服务器(storage.kapsa.io)返回的响应中，Content-Length却错误地显示为1字节

通过cURL命令直接请求同一URL时，服务器返回的是完整的文件大小(734103552字节)，这表明问题并非出在服务器端，而是浏览器处理响应时出现了异常。

技术分析

缓存机制的影响

经过深入排查，发现问题根源在于浏览器的缓存机制。在某些情况下，Chromium浏览器会将来自存储服务器的响应错误地缓存为仅1字节的200 OK响应。当后续请求同一文件时，浏览器直接从磁盘缓存中返回这个被错误缓存的响应，而不是向服务器发起新的请求。

Service Worker的角色

StreamSaver.js利用Service Worker来实现文件流式下载。正常情况下，Service Worker应该正确传递文件的完整大小信息。但在缓存污染的情况下，即使Service Worker获取了正确的文件大小信息，浏览器仍会返回被错误缓存的响应体。

跨浏览器差异

这个问题主要出现在Chromium浏览器中，而Chrome和Firefox表现正常，这表明：

1. Chromium的缓存实现可能存在某些边界情况处理不够完善
2. 不同浏览器对Service Worker和缓存机制的具体实现存在差异

解决方案

方案一：URL动态参数

最直接的解决方案是在下载URL中添加动态参数(如时间戳或随机数)，强制浏览器将每个请求视为唯一资源，从而绕过缓存：

const downloadUrl = `https://storage.kapsa.io/file.avi?t=${Date.now()}`;

这种方法简单有效，但会略微增加URL长度。

方案二：缓存控制头

更规范的解决方案是配置服务器返回适当的缓存控制头：

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

或者在StreamSaver.js中通过代码设置这些头信息。

方案三：Service Worker缓存管理

对于使用Service Worker的场景，可以在Service Worker脚本中显式管理缓存：

self.addEventListener('fetch', event => {
  event.respondWith(
    fetch(event.request, {
      cache: 'no-store'
    })
  );
});

最佳实践建议

1. 对于大文件下载：始终建议使用动态URL参数或禁用缓存，因为浏览器对大文件的缓存行为可能不一致
2. 跨浏览器测试：特别是使用Chromium内核的浏览器，需要额外关注缓存相关问题
3. 监控和日志：实现下载过程的监控，记录实际下载大小与预期大小的差异，便于及时发现类似问题
4. 渐进式增强：考虑为不支持Service Worker的浏览器提供备用下载方案

总结

StreamSaver.js是一个强大的前端文件流式下载解决方案，但在实际使用中需要注意浏览器缓存机制可能带来的问题。通过理解缓存工作原理并实施适当的缓存控制策略，可以确保文件下载功能的稳定性和可靠性。特别是在Chromium系浏览器中，对缓存问题需要给予特别关注。