我做了一些测试，并且在流式传输要下载的文件时遇到了一些问题（在响应中将 Content-Disposition 标头设置为附件）。以下行为对 Firefox 和 Chrome 都很常见，我将“浏览器”称为执行代码的实体，该代码不是由用户编写的代码。
当响应被发回时，流立即开始被消耗
event.respondWith()，这意味着虽然弹出窗口似乎询问用户他是否想要以及在哪里下载文件，或者他是否只是想拒绝下载，但流正在被消耗并且不停地拉数据。这似乎是一种疯狂的行为，是有意的，还是两个浏览器中的错误？如果用户拒绝下载或接受并稍后取消它，浏览器就会停止消费流，仅此而已。它从不调用
cancel()它的ReadableStreamDefaultReader实例，也不调用releaseLock(). 因此，流只是从底层源中提取数据，直到队列已满，然后在不知道任何情况下等待。我们应该如何处理它？
来自 Streams 规范（https://streams.spec.whatwg.org/#rs-cancel）：
cancel 方法取消流，表示消费者对流失去兴趣。提供的原因参数将提供给底层源的 cancel() 方法，该方法可能使用也可能不使用它。
所以我认为浏览器应该在它的实例上调用取消，ReadableStreamDefaultReader但 Firefox 和 Chrome 都没有。
- 此外，如果我在流的底层
ReadableStreamDefaultController实例上调用错误方法，浏览器仍然不会释放锁。