使用include或require可包含文件，区别在于失败时include发出警告而脚本继续，require则抛出致命错误并终止；为避免重复包含，应使用include_once或require_once；路径推荐用__DIR__构建绝对路径以确保稳定性。
PHP通过
include
或
require
语句将另一个PHP文件的内容插入到当前文件中，这让和模块化变得非常方便。简单来说，就是把一个文件的代码“粘贴”到另一个文件的指定位置执行。
解决方案
在PHP中，要包含另一个PHP文件，我们主要使用
include
或
require
语句。它们的语法非常直观：
// 使用 include 包含文件 include 'path/to/your/file.php'; // 使用 require 包含文件 require 'path/to/your/another_file.php';
当PHP解析器遇到这些语句时，它会暂停当前文件的执行，转而去读取并执行被包含文件中的所有代码。一旦被包含文件执行完毕，PHP会继续执行当前文件中剩余的代码。这意味着被包含文件中的变量、函数、类等都将在当前文件中可用。
例如，如果你有一个
config.php
文件定义了数据库连接信息：
立即学习“”；
// config.php <?php $dbHost = 'localhost'; $dbUser = 'root'; $dbPass = 'password'; $dbName = 'my_database'; ?>
然后，在你的
index.php
文件中，你可以这样使用它：
// index.php <?php require 'config.php'; // 包含配置文件 // 现在你可以在这里使用 $dbHost, $dbUser 等变量了 echo "数据库主机: " . $dbHost; // ... 进行数据库连接等操作 ?>
这种机制是构建任何复杂PHP应用的基础，它允许我们把代码拆分成小的、可管理的部分，比如头部、底部、功能模块、配置信息等，大大提高了代码的可维护性和复用性。
include
登录后复制
include
和
require
有什么核心，我该怎么选择？
这确实是初学者常问的问题，也是我在实际开发中需要反复考量的地方。
include
和
require
最本质的区别在于它们处理文件找不到时的行为。
当使用
include
语句包含一个不存在的文件时，PHP会发出一个
E_WARNING
级别的警告，但脚本会继续执行下去。这意味着即使某个可选的组件文件丢失了，你的应用的核心功能可能还能运行，只是某些部分会显示不完整或出错。
<?php echo "脚本开始执行。n"; include 'non_existent_file.php'; // 文件不存在，会发出警告 echo "脚本继续执行到这里。n"; // 这行会正常输出 ?>
而
require
则不同。如果
require
的文件不存在，PHP会抛出一个
E_ERROR
级别的致命错误，并立即终止脚本的执行。这意味着如果一个关键文件（比如数据库或核心函数库）缺失，你的应用根本无法运行，PHP会直接告诉你：“不行，我需要这个文件才能工作！”
<?php echo "脚本开始执行。n"; require 'non_existent_critical_file.php'; // 文件不存在，会抛出致命错误 echo "脚本继续执行到这里。n"; // 这行不会被执行 ?>
那么，我个人在选择时通常是这样考虑的：
- 对于核心、不可或缺的文件，我总是倾向于使用
require
登录后复制。
比如数据库连接配置、用户认证模块、关键的类定义文件等。如果这些文件缺失，整个应用程序就失去了运行的基础，那么直接终止脚本并显示错误信息反而是更好的做法，这能帮助我快速定位问题，而不是让应用在不稳定的状态下运行。 - 对于非核心、可有可无的组件，或者某些模板片段，
include
登录后复制可能更合适。
比如网站侧边栏的某个广告模块、某个可选的统计代码片段。即使这些文件丢失，网站的主体功能仍然可以正常工作，用户体验虽然受损，但不会导致整个网站崩溃。
不过，说实话，在现代中，我发现自己更多地在使用
require
，甚至是
require_once
。因为大多数时候，被包含的文件都承载着一定的职责，其缺失往往意味着功能不完整。让应用在不完整状态下运行，有时比直接报错更难调试和维护。所以，我的建议是，除非你明确知道某个文件是完全可选且其缺失不会对核心业务逻辑造成破坏性影响，否则，优先考虑
require
来保证应用的健壮性。
include_once
登录后复制
include_once
和
require_once
是什么，它们解决了什么痛点？
include_once
和
require_once
是
include
和
require
的增强版本，它们的核心作用是确保文件只被包含一次。这解决了在大型项目中一个非常常见的痛点：重复包含文件导致的错误和资源浪费。
想象一下，你有一个
functions.php
文件，里面定义了一些全局函数：
// functions.php <?php function greet($name) { return "Hello, " . $name . "!"; } ?>
如果你的
index.php
和
another_script.php
都包含了
functions.php
，而
another_script.php
又被
index.php
包含了一次，就会出现问题：
阿里达摩院寻光视频创作平台，以视觉AIGC为核心功能，用PPT制作的方式创作视频
74 // index.php <?php include 'functions.php'; // 第一次包含 include 'another_script.php'; // 假设这个脚本也包含了 functions.php ?> // another_script.php <?php include 'functions.php'; // 第二次包含 ?>
当
functions.php
被第二次包含时，PHP会尝试重新定义
greet
函数，这会引发一个
E_PARSE
级别的致命错误：“Cannot redeclare function greet()”。这就是重复包含带来的问题。除了函数重定义，类、常量、甚至某些全局变量的初始化都可能导致类似的问题。
_once
后缀的语句正是为了解决这个问题而生。它们在包含文件之前会检查该文件是否已经被包含过。如果已经被包含，PHP就会跳过这次包含操作。
-
：如果文件不存在，发出
include_once 'path/to/file.php';
登录后复制E_WARNING
登录后复制警告；如果文件已包含，则跳过；如果文件存在且未包含，则包含。
-
：如果文件不存在，抛出
require_once 'path/to/file.php';
登录后复制E_ERROR
登录后复制致命错误；如果文件已包含，则跳过；如果文件存在且未包含，则包含。
在实际开发中，尤其是在使用自动加载器（Autoloader）不那么普遍的老项目或特定场景下，
require_once
几乎是我的首选。它能够有效地防止因不小心或设计上的交叉引用导致的重定义错误，让我在组织代码时更加安心。比如，定义类、接口、特性的文件，或者包含配置常量、全局函数的库文件，我都会毫不犹豫地使用
require_once
。这不仅避免了运行时错误，也避免了不必要的重复文件读取和解析，尽管现代PHP的OPcache等优化机制已经大大降低了这部分开销。但从代码健壮性和逻辑清晰的角度看，
_once
系列是值得推荐的最佳实践。
文件包含时，相对路径和绝对路径的写法有什么讲究？
文件包含时的路径问题，可以说是我在职业生涯中遇到过无数次，也困扰过无数同事的“小坑”。路径写错了，轻则文件找不到，重则应用逻辑混乱。这里面的讲究，确实值得深入聊聊。
首先，我们要理解PHP在处理包含路径时的基准点。这和我们直觉中的“当前文件所在目录”可能有些出入。
-
相对路径（Relative Path）：
- 例如：
include 'config.php';
登录后复制或
include '../lib/functions.php';
登录后复制 - 关键点：PHP解析相对路径时，默认是相对于当前执行脚本的目录，而不是包含语句所在文件的目录。这听起来有点绕，我举个例子：
- 假设你的项目结构是：
/project/ ├── index.php ├── includes/ │ └── header.php └── lib/ └── utils.php
登录后复制 - 如果你在
index.php
登录后复制中写
include 'includes/header.php';
登录后复制，这很正常。
- 但如果在
header.php
登录后复制中又写
include '../lib/utils.php';
登录后复制，这里就可能出问题了。如果
index.php
登录后复制是入口文件，那么
../lib/utils.php
登录后复制是相对于
index.php
登录后复制所在的
/project/
登录后复制目录，所以它会正确找到
/project/lib/utils.php
登录后复制。
- 然而，如果另一个脚本，比如
/project/admin/dashboard.php
登录后复制也包含了
header.php
登录后复制，那么
header.php
登录后复制中的
../lib/utils.php
登录后复制就会相对于
/project/admin/
登录后复制去解析，试图找到
/project/lib/utils.php
登录后复制，这仍然是正确的。
- 真正的坑在于：如果
header.php
登录后复制自己被直接访问（这通常不推荐，但可能发生），或者被一个在不同深度的脚本包含，那么
../lib/utils.php
登录后复制的解析结果就会因“当前执行脚本”的不同而不同，导致文件找不到。
- 假设你的项目结构是：
- 例如：
-
绝对路径（Absolute Path）：
- 例如：
include '/var/www/html/project/includes/header.php';
登录后复制 - 优点：明确，不会因执行脚本位置变化而改变。
- 缺点：不灵活，如果项目部署在不同路径（比如和生产环境），需要修改代码。
- 例如：
为了解决相对路径的潜在混乱和绝对路径的硬问题，PHP提供了两个非常有用的魔术常量：
__DIR__
和
__FILE__
。
-
：包含当前文件（即包含
__DIR__
登录后复制__DIR__
登录后复制这个常量的文件）的目录的绝对路径。
-
：包含当前文件（即包含
__FILE__
登录后复制__FILE__
登录后复制这个常量的文件）的绝对路径和文件名。
我个人最推荐，也是我日常开发中几乎总是使用的模式，是结合
__DIR__
来构建基于当前文件目录的绝对路径。
// 假设这是 /project/includes/header.php <?php // 无论 header.php 被哪个文件包含，它都能正确找到相对于它自己的 utils.php // __DIR__ 在这里就是 /project/includes/ require_once __DIR__ . '/../lib/utils.php'; // 这样就能找到 /project/lib/utils.php // 或者包含同目录下的文件 require_once __DIR__ . '/another_include_in_same_dir.php'; ?>
这种写法的好处是，包含路径不再依赖于“入口脚本”的位置，而是依赖于“包含语句所在文件”的位置。这使得模块之间的引用关系变得清晰和稳定，无论你的
header.php
是从哪个入口点被调用，它内部的包含逻辑都不会出错。
另一个常见的绝对路径构建方式是使用
$_SERVER['DOCUMENT_ROOT']
，它代表Web服务器的文档根目录。
// 假设你的Web根目录是 /var/www/html，项目就在这里 require_once $_SERVER['DOCUMENT_ROOT'] . '/includes/header.php';
这种方式在Web应用中很常见，尤其是在Apache/Nginx配置了虚拟主机的情况下。但它也有局限性：只适用于通过Web服务器访问的PHP脚本，如果你的PHP脚本是通过CLI（命令行接口）运行的，
$_SERVER['DOCUMENT_ROOT']
可能为空或不准确。
总结一下我的经验：优先使用
__DIR__
来构建包含路径。 这种方式最健壮，最少出错，也最容易理解。它允许你构建一个独立的模块，这个模块内部的包含关系不会因为外部调用者的位置而改变。这对于构建可重用、可移植的代码库至关重要。
以上就是如何包含另一个php文件？php文件包含include/require用法的详细内容，更多请关注php中文网其它相关文章！
微信扫一扫打赏
支付宝扫一扫打赏
