流式读取本地File对象不能实现内存“绝对零占用”，但可将内存占用压降至与文件大小无关的恒定水平（通常几KB至几MB），其本质是单次仅加载一个数据块并及时释放，峰值内存仅取决于缓冲区大小。
流式读取本地 File 对象本身**不会导致用户系统内存“绝对零占用”**，但可以做到**内存占用恒定、与文件大小无关**——这才是它真正的优势。所谓“绝对零占用”是常见误解；准确来说，是把内存消耗从“随文件线性增长”压降到“仅取决于缓冲区大小”，通常几 KB 到几 MB 即可，无论上传 10MB 还是 10GB 文件。
为什么不是“零占用”，而是“可控恒定”？
浏览器中读取 File（本质是 Blob）时，底层仍需通过 FileReader 或 Stream API 拆分数据块。每次读取一个 ArrayBuffer 或 Uint8Array，该块会短暂驻留内存；上一块处理完并被垃圾回收后，下一块才加载。只要不同时持有全部块的引用，峰值内存就只等于单次读取的缓冲区大小（如 64KB）加上少量 JS 对象开销。
- 例如：用
stream().getReader()每次read()64KB，JS 引擎最多常驻一个 64KB 的Uint8Array+ 少量元数据 - 而
file.arrayBuffer()或file.text()会强制将整个文件解码为内存中的完整副本，1GB 文件 ≈ 占用 1GB+ 堆内存 - 操作系统层面，
File对象本身只是对磁盘文件的引用，不自动加载内容——这是“低开销”的前提
如何验证内存是否真正可控？
在 Chrome DevTools 的 **Memory 面板 → Allocation instrumentation on timeline** 中录制上传过程，观察堆内存曲线：流式读取应呈现锯齿状小幅波动（读一块→处理→释放→读下一块），而非陡峭单峰（一次性加载）。
- 关键指标：堆内存峰值稳定在 2–5MB 区间，不随文件增大而上升
- 对比实验：对同一 500MB 文件，分别用
file.arrayBuffer()和file.stream()读取，前者触发内存暴涨甚至页面崩溃，后者内存曲线平稳 - 注意排除干扰：关闭其他标签页，禁用可能缓存整个 Blob 的第三方库（如某些上传 SDK 默认启用内存缓存）
真正影响内存的关键操作有哪些？
流式读取只是起点，后续处理方式决定最终内存表现：
- ❌ 边读边拼接所有 chunk 到一个大
Uint8Array—— 立刻退化为传统高内存模式 - ✅ 边读边分块上传（如发给后端的 multipart/chunked 请求），每块上传完成即丢弃引用
- ✅ 使用
TransformStream做实时处理（如压缩、加密、校验），数据流经管道不落地存储 - ✅ 上传前计算哈希时，用
SubtleCrypto.digest()流式更新，避免累积原始数据
浏览器兼容性与实际限制
现代浏览器（Chrome 100+、Firefox 105+、Safari 16.4+）已全面支持 File.stream() 和 ReadableStream。但需注意：
- 部分旧版 iOS Safari 对大文件流式读取存在隐式缓冲，建议设置明确
type: 'bytes'并控制desiredSize - 如果使用
FileReader，必须配合readAsArrayBuffer()分段调用（非一次性readAsText），否则失去流式意义 - 即使流式读取，用户磁盘 I/O 和内核 Page Cache 仍有负载，但这不属于 JS 堆内存，不影响页面响应
