给出一些上下文：
最近，我和一位同事讨论了在PHP中使用自动加载器的问题。我主张支持他们，而他反对。
我的观点是，自动加载器可以帮助您最大限度地减少对手动源代码的依赖，这反过来又可以帮助您减少在包含大量可能不需要的大文件时消耗的内存量。
他的回答是，包含不需要的文件并不是什么大问题，因为一旦Apache子进程将文件保存在内存中，那么在包含文件之后，这部分内存将可用于后续请求。他认为，你不应该担心包含的文件的数量，因为很快它们就会全部加载到内存中，并在内存中按需使用。因此，内存问题较少，而且在文件系统上查找所需文件的开销更令人担忧。
他是个聪明的人，总是知道自己在说什么。然而，我一直认为Apache和PHP使用的内存是特定于正在处理的特定请求的。每个请求都被分配了一个等于memory_limit PHP选项的内存量，并且任何源代码编译和处理都只在请求的生命周期内有效。
即使有像APC这样的操作代码缓存，我认为单个请求仍然需要将每个文件加载到它自己的内存部分，而APC只是为响应过程预编译它的快捷方式。
我一直在搜索一些关于这方面的文档，但到目前为止还没有找到任何内容。如果有人能给我介绍一下关于这个主题的任何有用的文档，我将不胜感激。
更新：
为了澄清，自动加载器的讨论部分更多的是一个上下文：）。
可能还不清楚，但我的主要问题是Apache是否会将其资源集中在一起以响应多个请求（尤其是包含的文件使用的内存），或者每个请求是否都需要检索满足执行路径所需的代码，而与同一进程处理的其他请求隔离开来。
例如：文件1、2、3和4的大小相等，每个大小为100KB。请求A包括文件1、2和3。请求B包括文件1、2、3和4。
在他的脑海中，他认为请求A将在整个执行过程中消耗300KB，而请求B只会再消耗100KB，因为文件1、2和3已经在内存中了。
在我看来，它是300KB和400KB，因为它们都是独立处理的（如果由同一进程处理的话）。
这让他回到了他的论点，即"只包括批量"，因为你无论如何都会使用它，而不是我的"只包括你需要的东西来降低请求大小"。
这对于我如何构建PHP网站来说是相当基本的，所以我很想知道我在这里是否偏离了目标。
我也一直相信，对于大型网站来说，内存是最宝贵的资源，比文件系统检查自动加载器更值得关注，因为内核可能会缓存自动加载器。
你是对的，是时候进行基准测试了！
以下是赢得争论的方法：运行现实的基准测试，并站在数字的右侧。
我也进行过同样的讨论，所以我尝试了一个实验。使用APC，我尝试了一个带有单个单片include（包含所有Kohana）以及标准自动加载器的Kohana应用程序。最终的结果是，单次包含的速度更快，在统计上不相关（低于1%），但使用的内存略多（根据PHP的内存函数）。在没有APC（或XCache等）的情况下运行测试是毫无意义的，所以我没有麻烦。
所以我的结论是继续使用自动加载，因为它的使用要简单得多。对你的应用程序尝试同样的操作，并向你的朋友显示结果。
现在你不需要猜测了。
免责声明：我没有使用Apache。我再怎么强调也不为过，在自己的应用程序上在自己的硬件上运行自己的基准测试。不要相信我的经历会是你的。
你是更聪明的忍者，蚱蜢。
在请求类之前，自动加载器不会加载类文件。这意味着他们使用的内存最多与手动包含的内存量相同，但通常要少得多。
即使一个apache线程可以处理多个请求，类也可以从每个请求的文件中新鲜地读取，所以你的朋友"最终都被读取了"是站不住脚的。
您可以通过放置一个echo"foo"来证明这一点；在类文件中的类定义之上。您将在每个新请求上看到，无论您是在开始时自动加载还是手动包含整个类文件，该行都将被执行。
我找不到任何关于这方面的好的简洁文档——我可能会写一些带有内存使用示例的文档——因为我还必须向其他人解释这一点，并出示证据才能让它深入人心。我想zend的人并不认为有人会看不到自动加载的好处。
是的，apc等（像所有缓存解决方案一样）可以克服资源的负面影响，甚至可以在性能上获得一些小的提升，但如果在大量库上这样做并为大量客户端提供服务，则会消耗大量不必要的内存。尝试一些方法，比如在一个巨大的include文件中加载一块健康的pear库，同时处理500个访问页面的连接。
即使使用像Apc这样的东西，你也可以从将自动加载器与任何非名称空间的类（目前大多数现有的php代码）一起使用中受益，因为在处理大量类库时，它可以帮助避免全局名称空间污染。
这是我的作品。
我认为自动加载器是一个非常糟糕的主意，原因如下
- 我想知道我的脚本从什么地方获取数据/代码。使调试更容易
- 这也存在配置问题，因为如果您的开发人员之一更改了文件（升级等）或配置，并且事情停止了，则很难找到它的损坏位置
- 我还认为这是懒惰的编程
至于内存/性能问题，如果电脑正在努力解决这个问题，那么为它购买更多内存也同样便宜。