带着这个问题，我的目标是更好地理解 PHP 的内部工作原理。
假设您有一个 50K 的库。该库加载了一堆方便的函数，您可以在这里和那里使用。还假设您网站的 10% 的页面需要/使用这些功能。但是您的主页肯定需要它。
现在，问题是......您是否应该使用指向该库的全局包含 - 全面 - 以便所有页面（包括不需要库的 90% ）都可以获得它，或者您是否应该有选择地添加仅包括您需要的页面上的参考？
在回答这个问题之前，让我指出“为什么”我问这个问题......
当您包含该引用时，PHP 可能正在缓存它。所以我担心的性能打击可能是一次性的，而不是每次。一旦那一次不碍事，后续的负载可能不会像人们想象的那么糟糕。这完全是因为 PHP 部署的智能缓存机制——我对此并不深入了解，因此问题......
既然首页无论如何都需要那个库，那么为什么不让那个库在记忆中保持温暖和新鲜，并让它全面服务呢？
在回答这个问题时，请严格从缓存/性能的角度来处理这个问题，而不是从方便的角度来避免讨论转向编程风格和注意事项。
谢谢
我非常感谢您对性能的担忧。
简短的回答是，为了获得最佳性能，我可能有条件地将文件仅包含在需要它的页面上。
PHP 的操作码缓存将以缓存形式维护两个包含文件，因此您不必担心在使用其他类型的缓存时保持缓存“温暖”。缓存将一直保留，直到存在内存限制（不是 50K 脚本的问题）、更新源文件、手动清除缓存或重新启动服务器。
也就是说，操作码（PHP 字节码）缓存只是 PHP 解析过程的一部分。每次运行脚本时，都会处理字节码以构建在脚本中定义和可选使用的函数、类、对象和其他实例变量。这一切加起来。
在这种情况下，一个简单的更改就可以显着提高性能。保持绿色，每个周期都很重要:)
测量一下，你就知道了。
缓存在第一次命中后可能会受益，因为操作系统也会缓存它，但只保存 I/O 命中（当然，这不是什么）。但是，您仍然会受到处理的影响。如果您将 50K 的代码包含在“Hello World”页面中，即使您不执行任何代码，您仍然会为加载和解析这 50K 的源代码付出 CPU 和内存的代价。这部分处理很可能不会以任何方式缓存。
总的来说，今天的 CPU 非常便宜，因此它可能不“值得保存”。但这就是为什么您需要实际测量它，以便您自己决定。
我认为您所指的缓存是来自 APC 之类的操作码缓存？所做的只是防止 PHP 每次都需要解释源代码。您仍然会为您正在使用的每个包含或要求受到一些打击。一种范例是废弃程序函数并使用通过__autoload(). 这为大型应用程序提供了一种简单的按需使用策略。也同意威尔的观点，如果您担心，您应该衡量这一点。过早的优化永远不会有帮助。