我们谈了大清单报表的呈现方法，其实有时候这些报表还需要打印，比如银行打印流水对账单。

那么，打印是不是也要像呈现那样做一个缓存机制呢？

没有这个必要。打印和浏览不同，一般是从头到尾过一遍就行了，过程中没有翻页的需求。这样，只要流式读入数据逐步生成打印页就可以了，不会发生内存溢出的问题。

但这个做法仍然比较麻烦，特别是现代浏览器加强了安全控制，applet 等插件经常被禁用，打印功能常常不能直接由报表工具提供，而要采用 flash 或 PDF 方式来实现。用 flash 可以做到流式读取，但并不简单，还会导致插件与后台耦合性过高，影响安全性；而 PDF 方式就是一次性生成一个文档，没办法实现这种机制了。

我们来算算打印 100 万行记录是什么情况。

假设一页纸能打印 50 行记录（这已经算多了），100 万行记录就意味着 2 万页纸。2 万页的连续打印，有多少打印机能做到这个指标？你的用户真有这样的设备吗？2 万页纸大概有 2 米厚，什么打印机能把这些纸放进去？商用快速打印机一分钟也就 30 几页，就按 50 页 / 分钟算，2 万页也需要 7 个钟头！作为一个机械设备能连续工作这么久是不容易的。

而 100 万行记录需要占多大内存呢？一条记录算 1K 已经很大（毕竟一页要打印 50 行的），100 万行也就 1G 内存。这对于前端用于打印的普通 PC 来讲并不难满足。

这还是只算了 100 万记录的情况，如果把 100 万增加到 500 万，内存仍然可以承受，而打印机是万万吃不消了。也就是说，在现代计算机的内存容量下，打印这个功能采用全内存方式是没有问题的，几乎找不到需要流式读取的情况。作为一个要重复销售的商业软件，报表工具没必要去支撑这种极为罕见甚至根本不存在的应用场景。

这个计算结果，看起来有点荒唐，读者可能会觉得可笑。但这确实是和用户沟通需求时真实发生过的事情，实际上喊的记录行数比 500 万要大很多，而用户并没有认真计算过它意味着什么。经过一些常规计算我们就会发现，虽然有些用户在叫，大清单报表的打印其实是个伪需求。

大数据领域还有些类似的事，比如说 10T 数据想要 3 秒返回结果，用户却不会想到这很可能意味着 1 万块硬盘。

严谨认真一点，会推出许多想不到的有趣结论 :)。