spa中不存在传统“文件流未关闭”，但存在等效泄漏：fetch响应体未消费、filereader未清理、blob url未revoke，导致内存滞留与oom。
不正确的流闭合在长期运行的 SPA 应用中本身不直接发生——因为浏览器环境没有传统意义上的“文件句柄”概念。但问题本质是**类比迁移错误**：开发者常把后端或桌面端的资源管理逻辑（如未关闭 InputStream、FileStream）套用到前端，误以为 fetch 响应体、Blob、FileReader 或 WebSocket 连接也需“手动 close 流”，从而引发真实泄漏。真正危害来自对异步资源生命周期的误判，而非流对象本身未关闭。
为什么 SPA 里不存在“文件流未关闭”但存在等效泄漏
浏览器中：
- fetch 返回的 Response.body 是 ReadableStream，但它由浏览器自动管理；调用 .getReader() 后若不读完或不主动 cancel，才会导致底层连接挂起、内存滞留
- File 对象和 Blob 是引用计数型资源，不调用 revokeObjectURL 不会立即释放 URL，但不会耗尽系统句柄——它只拖慢 GC，占用堆内存
- 没有 ulimit 或 lsof，也没有 /proc/pid/fd；句柄泄漏是操作系统层概念，前端运行在沙箱中，受限的是内存与事件循环队列
SPA 中最接近“流未关闭”的三类实际泄漏场景
这些行为在效果上等同于后端的“未关闭流”：持续占用不可回收资源，随时间推移导致卡顿、OOM、白屏：
- fetch 响应体未消费也未中断：调用 fetch() 后仅检查 status，却不读取 response.json() / response.text()，也不调用 reader.cancel()；尤其在 abortable 场景（如页面切换）下，未传 signal 或未 abort controller，会导致请求悬停、内存驻留、连接池占满
- FileReader 或 StreamReader 长期绑定未清理：监听 load 事件后，未在组件卸载时 removeEventListener；更隐蔽的是用箭头函数注册，导致无法解绑，使整个组件闭包无法释放
- Blob URL 泄漏 + 大文件驻留：通过 URL.createObjectURL(blob) 创建预览链接后，忘记在组件销毁或 blob 不再需要时调用 URL.revokeObjectURL(url)；大视频/图片 blob 会持续占据堆内存，Chrome 中可观察到 Memory 面板中 Detached DOMTree 或 Blob 对象 Retained Size 居高不下
如何确认这是“类流泄漏”而非普通内存增长
打开 Chrome DevTools → Memory 面板，按以下路径验证：
- 拍摄快照前，强制触发一次 GC（点击垃圾箱图标），确保基线干净
- 执行可疑操作（如上传文件→预览→切换路由→返回），重复 2–3 轮
- 再拍快照，切换 Comparison 视图，筛选 Blob、ReadableStream、FileReader 构造器，看 Retained Size 是否稳定增长
- 重点检查 Distance ≤ 4 的 Blob 实例——它们大概率被全局变量、未清除的事件监听器或缓存 Map 强引用着
修复关键：用信号机制替代“手动关流”思维
前端没有 close()，只有 signal、abort、revoke、removeEventListener 这四类主动切断动作：
- 所有 fetch 加
signal: AbortController.signal，组件 unmount 时调用controller.abort() - FileReader 实例保存在组件 ref 或 this._reader 中，onload/onerror 后显式设为 null，并在卸载钩子中检查是否 pending，是则 abort()
- Blob URL 必须成对出现：
create → 使用 → revoke；推荐封装 hook，如useBlobUrl(blob)内部自动管理 revoke - 避免将流相关对象（如 reader、decoder）存入全局 store 或静态 Map；改用 WeakMap 关联 DOM 元素与临时状态
