病案室要数字化十年归档。三千页住院病历，计划一天扫完。

扫描软件在第一百九十页时停了。不是暂停，是崩溃——进程消失，内存归零，一百九十页的进度全部丢失。重启软件、重新加载驱动、从第一页重来。扫到第二百页，又崩了。三千页的目标，在两百页的天花板前反复碰壁。

崩溃的临界点：两百页之后的沉默

扫描软件将所有已扫描图像加载到内存。300 DPI彩色A4一页约25MB，两百页就是5GB——超过浏览器和插件的内存承受范围。内存填满，扫描变慢，程序无响应，最后进程消失。

崩溃的代价不只是重启。每次重启软件、连接扫描仪、配置参数需五到十分钟。三千页以两百页为天花板，至少十五次重启——三小时的工作膨胀成整天。

ADF自动进纸场景更致命。五十页放进进纸器连续扫描，第三十五页崩溃——纸还在走，软件已经不管了。纸张卡住，扫描仪报错，重新整理再放进去。崩溃不只丢进度，还伤硬件。

内存的天花板：桶的容量有限

传统扫描的存储模型是桶——每一页图像进入内存后留在那里直到扫描结束才统一输出。桶有固定容量，装满就溢出，溢出就崩溃。

桶模型隐含假设扫描是短时任务。二十页、五十页，桶能装下。但真实扫描常常是长时任务——医院归档三千页，法院卷宗八百页，政府文件上千页。桶为短跑设计，遇到了马拉松。

两百页之前一切正常。两百页之后桶满——不是跑得慢了，是跑不动了。内存溢出不是渐进衰减而是骤然停止，中间没有预警区间。

磁盘缓存：从桶到河

NexScanner的磁盘缓存把存储模型从桶变成了河。

河的逻辑：每一页图像扫描完成后立即写入磁盘，然后从内存释放。水流入河，水流走，河面水位始终不变。内存占用量与总页数无关——扫三页和扫三千页，内存消耗恒定。

不存在"满溢"的临界点。没有天花板，没有崩溃窗口，没有"第几页会崩"的问题。扫描可以从第一页一直走到最后一页，中间不需要停下来清空内存、不需要分批次重启。

磁盘缓存是可选的。短时任务——扫一份二十页的记录，内存模式够快。马拉松任务——三千页批量归档，切换到磁盘缓存，一次到底。选择权在用户手中，能力始终就位。

三千页的真实场景

医院病案归档是最典型的马拉松。三千到五千页一个批次，ADF装满五十页自动连续扫描。加上双面模式——五十张纸正反面同时采集，一次进纸产出一百页图像。没有缓存，双面扫描让内存压力加倍；有了缓存，双面+ADF+三千页依然流畅。

法律卷宗需要耐力。数百页合同、鉴定报告、通信记录，扫描必须连续完成——中断意味着分批拼凑，页码混乱，证据链完整性受损。

政府文件数字化也不接受碎片化。几千页连续扫描，断一次就要重新整理排序。磁盘缓存让整批文件一次扫完、一次归档。

每个场景的核心需求不是"扫得快"而是"扫得完"。第一百页崩溃可重来，第三千页崩溃几乎不可承受。磁盘缓存消除了崩溃的可能性，也消除了崩溃位置的不确定性。

不崩溃是底座，不是装饰

扫十页快很容易，任何插件都能做到。扫三千页不崩溃很难，只有磁盘缓存架构能做到。

NexScanner的磁盘缓存让"不崩溃"成为默认行为。从"扫到崩溃为止"到"扫到完成为止"——不是效率提升，是逻辑翻转。崩溃不再是固有风险，而是被架构排除在外的可能性。

插件的其他能力都建立在这个底座之上。跨平台协议适配（TWAIN/WIA/SANE）让任何系统的扫描仪都能被调用——前提是扫描不崩溃。图像智能处理（空白页过滤、打孔去除、黑边修剪、OCR）让输出质量更高——前提是扫描先完成。几行JavaScript让集成极简——前提是底层可靠，开发者才敢把功能交给插件。

一场马拉松，选手必须先跑到终点，才有人关注他跑得多快。磁盘缓存确保比赛完成——这是所有其他能力得以展示的前提。