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