本文定义项目如何评估更大输入、提供可信进度并研究流式处理，同时不削弱补丁兼容性。 它是一份可行性与测量计划，不承诺所有浏览器或移动设备都能处理某个固定尺寸。
当前约束
当前 diff 算法在构建和遍历后缀数组时，需要随机访问完整的旧、新输入。原生调用虽然 接收文件路径，内存使用仍然与输入规模成比例。Web 的 TypedArray 输入仍需要传入 Worker 与 WebAssembly 线性内存；Blob/File 通过 WORKERFS 避免主线程中的额外 完整副本。Node 发布工具则通过 NODEFS 挂载宿主路径。
应用补丁现在会以 64 KiB 分块读取旧文件和压缩补丁，并增量写入同目录临时输出。 Web 仍返回完整 Uint8Array，因此浏览器边界会保留最终结果，但 C 核心不再同时分配 完整旧文件与输出缓冲区。
测量矩阵
默认 1、10、50 MiB 基准继续作为成本较低的趋势线。显式的大文件 profiling 使用 16、64、128 MiB 确定性输入，每 4 KiB 修改一个字节：
BENCHMARK_OUTPUT=/tmp/web-large.json yarn benchmark:large:web
BENCHMARK_OUTPUT=/tmp/native-large.json yarn benchmark:large:native每个尺寸在独立进程运行，以便比较峰值常驻内存。需要记录 runtime、diff 和 patch 耗时、补丁尺寸、往返结果与峰值常驻内存。Web 报告还记录往返结束后的 external 与 ArrayBuffer 存活内存。只比较相近硬件和工具链上的结果；共享 Runner 数据只作为诊断 artifact，不作为 PR 阈值。 大文件 profiling 命令会把单个尺寸的失败保留在 JSON 报告中并继续其他样本；生成了 报告不代表全部尺寸通过。默认基准遇到任何失败时仍以失败状态退出。
当每个请求尺寸都在宿主机记录的内存预算内完成并验证往返，或以明确的资源错误失败 时，profiling 才算通过。崩溃、临时输出泄漏、结果损坏或静默降级都属于失败。测量 结果不代表更大尺寸或更低内存设备也获得支持。
首份 Apple M3 Pro / Node 22 记录已检入 benchmarks/。原生端以约 2.37 GiB 峰值 RSS 完成 128 MiB；Web 端以约 2.09 GiB 峰值 RSS 完成 64 MiB，但 128 MiB 会耗尽 WebAssembly 内存预算并被归类为 ERESOURCE；项目仍不宣称 Web diff 支持 128 MiB。
进度语义
进度必须来自真实算法检查点，不能使用定时器或动画猜测完成比例。跨平台 job 使用 以下阶段：
reading：验证输入并加载核心需要的数据。processing：执行后缀数组/diff 工作或重建补丁。writing：原生端持久化并原子提交输出；Web 端在结果 buffer 可以传输时完成此阶段。
原生与 Web job 都已暴露这些阶段。Web 进度从插桩后的 C 检查点经 WebAssembly 和 Worker 消息传递，不使用定时器或模拟百分比。公开 callback 保持可选，未传入时不会 改变结果或错误行为。
流式处理可行性
真正的流式 diff 不是当前 BSDiff 算法的兼容优化：后缀数组构建和匹配需要全局随机 访问两份输入。要实现它，必须选择另一种算法或新补丁格式，并明确兼容与迁移策略。
补丁应用已经使用有界 C 实现：按块读取旧文件与压缩后的 control/diff/extra 流， 写入临时目标，同时保留 ENDSLEY/BSDIFF43 约定。浏览器 Blob/File 使用只读 WORKERFS 挂载；公开 API 仍返回完整 buffer，因此直接写浏览器文件句柄继续作为渐进 增强能力。
实施顺序
- 保持原生与 Web 的 16/64/128 MiB 耗时和峰值内存基线。
- 在可比设备上测量已经完成的 C/WASM 进度与有界 patch 路径，比较改造前后的
- 评估直接写入浏览器文件句柄，同时保持取消、资源限制、清理与逐字节兼容。
- 流式 diff 算法或新补丁格式继续作为独立提案。
峰值内存。
所有生产 API 都必须保持确定性输出验证，在大额分配前尽可能拒绝超限尺寸，在取消和 失败时清理资源，并通过 Android API 24、iOS Simulator、浏览器与跨平台 golden patch 测试。
非目标
- 把单次桌面测量结果宣传为移动端支持保证。
- 没有新测量记录就宣称支持超过 128 MiB 的输入。
- 将用户文件上传到托管服务；站点工具继续只在本地处理。
- 为了让耗时操作看起来有响应而引入模拟进度。