按照我一直使用的旧习惯，需要超过包含。基本上这两个函数是完全相同的 - 除了require如果文件不存在会抛出错误并因此停止脚本 - 其中include只会抛出警告并继续脚本，就好像什么都没发生一样。
通常，当我动态包含文件时，我会使用类似于 if file_exists 然后需要它的东西。看起来像这样：
<?php if (file_exists($file)) { require $file; } else { /*error handling*/ } ?>
据我所知，如果我错了，请纠正我，这被广泛接受为最佳实践和最有效的处理方式。
但是我想到了另一种方法，在我看来似乎更快，更聪明：
<?php if (!include $file) { /* error handling */ } ?>
我还没有测试过它，但在我看来，它应该比 file_exists/require 组合更快，因为这需要 2 个硬盘驱动器交互，而包含方法只需要一个。
从我的测试来看，它按预期工作。它继承了您期望的范围，并且其中设置的变量是可访问的。
有什么理由不这样做吗？
编辑：错别字
编辑 2：反对这一点的一个论点可能是当它试图包含不存在的文件时抛出的E_Warning。这可以通过在包含处传递 @ 来避免...喜欢这个：
<?php if(!@include $file) { /* error */ } ?>
不，这不是"最佳实践"。
您将在以下三种情况之一中包含文件：
- 如果您需要它的功能 - 换句话说，如果您的代码在没有该文件的情况下无法运行
- 如果您的代码可以使用该文件中的某些功能来提供额外的功能，但没有它就可以工作
- 如果你的代码可以通过包含该文件来增强，但没有它的功能没有什么不同(一个例子是包括一个原生SSL库，而不是使用纯PHP库作为后备;另一个例子是"我需要这些库之一"的情况，除了最后一个之外，所有库都属于这个分组，最后一个你尝试算作"我需要这个"并使用第一个项目符号(
唯一应该使用此处显示的 if-include 模式的情况是在第二种或第三种情况下，在这种情况下，拥有文件很好，但不是必需的。在第一种情况下，您绝对不应该这样做 - 您应该使用 require .在第二种情况下，您应该强烈考虑使用不带 if 语句的include。在第三种情况下，您可以使用条件include，但请参阅下文。
管理的一般"最佳实践"包括在 PHP 项目中，您可以期望 include 语句永远不会失败而不会破坏程序，这是定义__autoload并让它处理您的纠错、文件存在检查等。
为了解决您的假设，即尝试包含然后检测失败会更快：微优化，尤其是没有经验数据支持的微优化，是万恶之源。它是否更快并不重要。首先，确定您是否有问题。如果是，那么确定你的include语句在运行时是否足够重要，以至于它们值得你花费程序员的时间使它们稍微好一点。如果是，则测试备用实现是否正常工作。如果是，则对两个版本进行基准测试，看看替代版本是否更快。只有这样，您才应该考虑部署它。