require在文件缺失时抛出致命错误并终止脚本，适用于关键文件；include仅发出警告并继续执行，适用于非关键文件；两者均有_once变体以避免重复引入导致的重定义错误；现代PHP开发中推荐使用Composer自动加载管理类文件，require用于核心配置和引导文件，include多用于视图模板片段，确保应用健壮性与可维护性。
PHP中
include和
require的核心区别在于它们对引入文件失败时的处理方式：
require会在文件找不到时抛出致命错误（
E_COMPILE_ERROR），导致脚本立即停止执行；而
include则只会发出一个警告（
E_WARNING），脚本会尝试继续运行。简单来说，
require用于引入那些对脚本运行至关重要的文件，而
include则适用于那些非关键性的、即使缺失也不会完全破坏整个应用逻辑的文件。
在PHP的日常开发中，我们经常需要将代码拆分成多个文件，以提高可维护性和复用性。
include和
require便是实现这一目的的两种基本构造。从我个人的经验来看，选择哪一个，往往取决于你对文件依赖程度的判断。
如果一个文件包含了你的应用启动所必需的配置信息、核心类定义，或者关键的函数库，那么毫无疑问，我会倾向于使用
require。因为一旦这些文件缺失，整个应用根本无法正常工作，让脚本立即停止并报错，反而是一种更清晰、更安全的处理方式。它能让你迅速定位问题，而不是让一个半瘫痪的应用继续运行，可能导致更难以追踪的逻辑错误。
反之，如果引入的文件只是一个可选的模板片段、某个页面的侧边栏内容，或者一些非核心的辅助性脚本，即使它未能成功加载，应用的主体功能依然可以运行，只是用户界面可能显示不完整，或者某个次要功能失效。在这种情况下，
include就显得更为宽容。它会发出一个警告，告诉你文件没找到，但脚本不会因此中断，用户体验或许会受到一点影响，但至少不会看到一个白屏或服务器错误。这种“容错”机制在某些场景下是很有用的，比如动态加载用户自定义的插件，即使插件文件损坏或缺失，核心系统依然能保持运行。
立即学习“PHP免费学习笔记（深入）”；
此外，我们还有
include_once和
require_once这两个变体。它们的作用是在引入文件之前，先检查该文件是否已经被引入过。如果已经引入，则不再重复引入。这对于避免重复定义函数、类或常量，从而引发“Cannot redeclare...”之类的致命错误至关重要。我个人几乎总是优先使用
_once版本，除非我明确知道某个文件需要被多次引入且不会产生副作用（这种情况非常少见）。
什么时候应该优先使用 require 而不是 include？
在我看来，选择
require的时机，通常是当被引入的文件承载着“不可或缺”的职责时。试想一下，如果你的数据库连接配置、核心路由定义，或者一个全局性的服务容器类文件丢失了，你的应用还能正常运作吗？显然不能。在这种情况下，使用
require是明智之举。它强制性地要求这些关键组件必须存在，一旦缺失，PHP会立即抛出一个致命错误，终止脚本执行。这听起来可能有点“粗暴”，但实际上，这种“早失败，早发现”的策略对于生产环境的稳定性至关重要。它能防止应用在缺少关键依赖的情况下继续运行，从而避免更深层次、更难以诊断的逻辑错误。
例如，一个应用程序的核心启动文件（如
index.php）通常会
require一个包含应用配置或自动加载器设置的文件。如果这些文件不存在，整个应用就无法初始化，直接报错比继续执行并产生未知行为要好得多。我经常将
require用于引入那些定义了全局常量、关键函数库或核心类（在不使用Composer autoloading的情况下）的文件。这就像是建造一座房子，地基和承重墙是必须的，如果它们缺失，房子就根本无法建造起来，直接停止施工是唯一的选择。而
include则更像是房子的装饰品，即使缺少一些，房子主体依然屹立。
include_once 和 require_once 的存在解决了哪些实际问题？
include_once和
require_once的存在，主要解决了在复杂应用中重复引入文件可能导致的一系列问题，这在我日常的开发中是一个非常实际且常见的痛点。
最直接的问题就是避免重复定义。假设你有一个文件
functions.php，里面定义了一个名为
my_utility_function()的函数。如果你在不同的地方多次使用
include 'functions.php';，那么当脚本第二次尝试引入这个文件时，PHP会抛出一个致命错误，提示“Cannot redeclare function my_utility_function()”。同样的问题也适用于类和常量。
_once后缀的引入机制，在文件被引入之前会检查一个内部列表，如果文件路径已经在这个列表中，它就会跳过本次引入。这就像是给文件打了个“已处理”的标记，确保每个文件只被处理一次。
其次，它解决了潜在的副作用和状态管理问题。有些文件在被引入时可能会执行一些初始化代码，或者修改全局变量的状态。如果这些文件被重复引入，这些初始化代码可能会被重复执行，导致意料之外的副作用或状态混乱。比如，一个文件可能会创建一个数据库连接，如果多次引入，可能会创建多个不必要的连接，浪费资源。
_once确保这些初始化逻辑只运行一次，保持了应用状态的清晰和一致性。
举个简单的例子：
// config.php // main.php
如果没有
_once，第二次
include 'config.php'会导致
APP_NAME常量重复定义错误，而
include_once则优雅地避免了这个问题。这对于构建大型、模块化的应用至关重要，它让开发者无需担心某个文件会在不知情的情况下被多次加载，从而大大简化了依赖管理和错误排查。
在现代PHP开发中，这些文件引入机制的最佳实践是什么？
在现代PHP开发中，尤其是在使用框架或构建大型应用时，文件引入机制的最佳实践已经从简单的
include/
require，演进到了更高级、更自动化的方式。我个人认为，有几个核心点值得强调：
拥抱自动加载（Autoloading）：对于类文件，手动使用
require
或include
几乎已经成为过去式。现代PHP应用普遍通过Composer及其PSR-4自动加载标准来管理类文件的加载。你只需定义好命名空间和对应的目录，Composer就会自动为你生成一个高效的自动加载器。这意味着你不再需要手动编写require_once 'path/to/MyClass.php';
，而是可以直接实例化类，PHP会在需要时自动找到并加载它。这极大地提升了开发效率，减少了手动维护文件路径的麻烦，也让代码结构更加清晰。require
用于关键配置和引导文件：尽管自动加载盛行，但对于应用程序的入口文件（如index.php
）和核心配置文件，require
仍然是首选。例如，你的index.php
文件通常会require __DIR__ . '/vendor/autoload.php';
来加载Composer的自动加载器，或者require __DIR__ . '/config/app.php';
来加载应用的基本配置。这些文件是应用启动的基础，它们的缺失将导致整个系统崩溃，因此使用require
确保它们的存在是合乎逻辑的。include
用于视图/模板片段：在MVC（Model-View-Controller）架构中，include
常用于加载视图文件或视图中的局部模板片段。例如，一个控制器可能会include 'views/header.php';
、include 'views/posts/list.php';
和include 'views/footer.php';
来组合一个完整的页面。在这种场景下，即使某个视图文件意外缺失，通常也只会导致页面显示不完整，而不是致命错误，这符合include
的容错特性。当然，更高级的模板引擎（如Twig、Blade）提供了更强大的视图管理功能，但底层原理上仍与文件引入相关。避免在循环或条件语句中滥用
require
/include
：尽管语法上允许，但在循环或频繁执行的条件语句中动态地require
/include
文件通常不是一个好主意。这会增加文件I/O操作，影响性能，并可能导致难以预测的行为。如果需要动态加载组件，可以考虑使用更高级的依赖注入容器或工厂模式。
总而言之，现代PHP开发倾向于将文件引入的职责分层：核心的类文件交给Composer自动加载；关键的引导和配置使用
require；而视图或非核心的、可容错的组件则可以考虑使用
include（或更专业的模板引擎）。这种分层策略既保证了应用的健壮性，又提升了开发效率和代码的可维护性。
