在阅读了基于文件的PHP会话对性能的影响之后，我开始思考。这是否意味着包含大量文件的PHP脚本也不好？因为它包含一个文件，或者这与检索会话数据文件的方式不同？

您应该使用spl_autoload_register()和oop。这样，无论您的项目目前有多小，或者随着时间的推移会有多大(排除这种可能性是愚蠢的)，PHP将只包含它所需要的，不多也不少。

这是运行时RAM使用、代码的可维护性和硬盘延迟时间的影响之间完美的面向未来的平衡，我想说，如果您正确地模块化了代码(当然，xdebug在这里有帮助)。

尽管如此，它暗示了包含未使用的文件的坏处。

由于php.ini指令include_path，无论以何种方式(spl_autoload_register()或其他方式)，都应使用绝对路径来包含文件，php在使用相对路径时会搜索该路径。

还有一个小的额外说明，为什么"include'foo.php"的工作方式类似于"include'/foo.php'"(包含文件的"普通"方式)：这是因为默认情况下目录"."是include_路径的一部分。

我认为，每个玩弄PHP的人都到了他们的库变大的时候，对性能的担忧就出现了。

我的经验是，是的，如果您总是加载所有的库，那么这将耗尽宝贵的内存(每个进程只分配一个固定的兆字节数)。我的源代码文件重300-400KB(带注释)，每个脚本实例占用2-3MB。考虑到一个脚本只有16-32MB，并且有许多共享主机，这是非常重要的。此外，处理如此巨大的文件通常在每次请求最多半秒的时间内完成，这实在是太多了。

所以，分开是绝对必要的，而且很容易与自动加载和配偶。查看我对这个问题的回答，了解一些关于如何明智地拆分代码的建议。还有一个关于如何组织大型PHP项目的问题的链接，它产生了很好的结果。我正在自己找出完美的结构，但还没有完成。：)

其实没那么糟。这可以通过以下事实来证明：没有人试图创建一个编译器来使整个PHP应用程序成为一个单独的脚本。

如果您真的使用php的microtime函数来测量花费了多少时间，它将在十亿分之一秒之内。

就我个人而言，页面处理的数据总是比源文件包含的大小和数量有更多的问题。但是，我在抽象层中编写了大量参数化的代码(这与剪切粘贴编程相反)，因此同一代码只需更改六分之五的简单参数就可以完成许多不同的工作。

就像查查查102所写的，这并没有那么糟糕。

但它还取决于实际的脚本文件。

实际上，您应该对代码进行概要分析，xdebug非常适合这样做。

澄清：概述和比较。如果可以的话，避免使用很多小的脚本文件，但是仍然要保持源代码的有序性(一个有数千行的脚本不适合编辑)。一个分析器会给你一些数字来找到一个很好的平衡点。

另一种选择是"懒惰"包含文件，例如，在使用它们之前需要使用一次它们(例如实例化一个类)，这样就不会发生一整批未使用的包含。

我已经使用过Zend特性(register autoload)，但我不知道它是PHP的通用特性，还是它不是但存在于其他框架中…

包含很多小文件比包含一个大文件性能差，这就是为什么存在像APC这样的缓存引擎。