字节码下载与流下载：两个概念的最小边界
本条记录先划清边界：字节码下载强调把整个可执行单元一次性取回再交由运行时处理；流下载强调数据在传输过程中即被消费。二者差别不在协议，而在“何时开始使用数据”。
分类入口
按档案类别归置，便于逐条比对两种下载方式的差异。
资料条目
共 10 条，按归档编号排序。
加载时序对照：先完整后执行 vs 边到边解析
整理两种时序图：前者需等待传输完成才进入执行阶段，启动延迟与体积正相关；后者在首个数据块到达后即可开始解析，延迟更多取决于首包时间而非总体积。
内存曲线记录：整体缓冲与分片回收
档案显示，整体下载通常需要一块与资源体积近似等量的缓冲；流下载按块处理，处理完的块可被回收，峰值占用更接近于“单块大小 + 处理上下文”。
进度可观测性：百分比条目与事件流条目
整体下载天然具备总长度，可给出精确百分比；流下载若响应头缺少长度信息，则只能记录已接收字节数，进度表达从“比例”变为“累计”。
中断之后：重新取回与从断点接续
整体下载一旦中断，若未保存分片则需全部重来；流下载在消费侧往往已处理部分内容，续传需在应用层记录偏移量，代价与实现复杂度均需单独评估。
完整性校验的位置差异
整体下载可在使用前对完整文件做哈希比对；流下载的校验只能随块推进，采用分段摘要或末尾汇总，发现异常时可能已有部分数据被消费。
大体积资源：为何更偏向流式处理
当资源体积远超可用内存时，流式处理几乎是唯一稳妥路径；档案中多处案例表明，整体下载在此类场景下容易触发内存压力与垃圾回收抖动。
小体积与强一致需求：整体下载的保留理由
体积小、需要在使用前确认完整性的资源，整体下载仍更直接：一次取回、一次校验、一次使用，路径短且行为可预测，调试成本也更低。
弱网与高延迟下的表现记录
高延迟环境中，流式处理能更早暴露首包结果，用户感知启动更快；整体下载则可能长时间停留在无反馈状态，需额外的等待提示设计。
选型清单：从五个维度做一次对照
按体积、内存上限、是否需要即时解析、校验强度、实现复杂度五个维度列出对照项，形成一张可直接复用的小型决策表，归档为本次整理的总纲条目。
使用指引
按档案整理的阅读顺序，四步走完一轮对照。
- 先读总纲：从归档编号 A-001 开始，确认两个概念的最小边界，避免后续条目理解偏差。
- 再看对照：依次阅读加载时序、内存占用、进度反馈三条，形成横向对照印象。
- 回溯场景：结合自身资源体积与网络条件，在适用场景条目中定位最接近的案例。
- 落地取舍：使用 A-010 的选型清单做一次自查，把结论写回本地记录，便于后续复核。
上传 / 举报
档案由编者与读者共同维护。
免责声明：本站为资料整理型档案库，条目内容基于公开技术资料与编者实测归纳，仅供参考与学习使用，不构成任何形式的技术承诺或商业建议。读者在实际工程中采用何种下载方式，应结合自身环境独立验证。转载或引用请注明来源条目编号。