引用一些famous words :
“Programmers… often take refuge in an understandable, but disastrous, inclination towards complexity and ingenuity in their work. Forbidden to design anything larger than a program, they respond by making that program intricate enough to challenge their professional skill.”
在解决工作中的一些普通问题时，我想到了这个想法，但我不太确定如何解决。我知道我不会实现这个，但我很好奇最好的解决方案是什么。 :)
假设您有一个包含 JPG 文件和一些奇怪的 SWF 文件的大集合。 “大”是指“几千”。每个 JPG 文件大约为 200KB，而 SWF 文件的大小可达几 MB。每天都有一些新的 JPG 文件。因此，所有内容的总大小约为 1 GB，并且正在缓慢但稳定地增加。文件很少更改或删除。
用户可以在网页上单独查看每个文件。然而，也有希望让他们一次下载一大堆。这些文件附加了一些元数据(日期、类别等)，用户可以根据这些元数据过滤集合。
最终的实现将是允许用户指定一些过滤条件，然后将相应的文件下载为单个 ZIP 文件。
由于标准数量足够多，我无法预先生成所有可能的 ZIP 文件，必须即时生成。另一个问题是下载量可能非常大，对于连接速度较慢的用户来说，很可能需要一个小时或更长时间。因此，对“resume”的支持是必不可少的。
不过，从好的方面来说，ZIP 不需要压缩任何东西——反正文件大部分都是 JPEG。因此，整个过程不应比简单的文件下载更占用 CPU。
然后我发现的问题是:
- PHP 有脚本执行超时。虽然它可以由脚本本身更改，但是完全删除它不会有任何问题吗？
- 使用 resume 选项，过滤结果可能会因不同的 HTTP 请求而改变。这可以通过按时间顺序对结果进行排序来缓解，因为集合只会越来越大。然后，请求 URL 还将包含它最初创建的日期，并且脚本不会考虑早于该日期的文件。这够了吗？
- 通过 PHP 传递大量文件数据本身不会影响性能吗？
您将如何实现？ PHP 能胜任这项任务吗？
添加:
现在有两个人建议将请求的 ZIP 文件存储在一个临时文件夹中，并像通常的文件一样从那里提供它们。虽然这确实是一个显而易见的解决方案，但有几个实际考虑因素使其不可行。
ZIP 文件通常非常大，从几十兆字节到几百兆字节不等。用户请求“一切”也是完全正常的，这意味着 ZIP 文件的大小将超过 1 GB。此外，还有许多可能的过滤器组合，其中许多可能会被用户选择。
因此，ZIP 文件的生成速度会非常慢(由于数据量和磁盘速度的原因)，并且会多次包含整个集合。如果没有一些非常昂贵的 SCSI RAID 阵列，我看不出这个解决方案如何工作。
最佳答案
这可能是您需要的: http://pablotron.org/software/zipstream-php/
此库允许您在不交换到磁盘的情况下构建动态流式 zip 文件。
关于php - 使用 PHP + Apache 高速即时生成 ZIP 文件？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/990462/