是，require_once会拖慢脚本执行速度，因其每次调用需查询已加载文件哈希表并做字符串比对；在高频循环或路径未缓存等场景下开销显著，而require无此判断步骤，性能更优。
require_once 会拖慢脚本执行速度吗
会，但影响通常很小；真正拖慢的不是 require_once 本身，而是它每次都要查一遍已加载文件列表——PHP 内部维护一个哈希表（EG(included_files)），每次调用都会做一次字符串比对和查找。在普通项目里，几十次调用几乎感知不到；但若在高频循环里反复调用（比如每请求 500 次 require_once 'config.php'），开销就不可忽视了。
什么场景下 require_once 的性能代价最明显
以下情况会让 require_once 的开销放大：
- 文件路径是相对路径（如
'../lib/Helper.php'），触发完整include_path搜索链，每次都要遍历多个目录尝试打开文件 - 路径未被 OPcache 缓存（例如启用了
opcache.enable_cli=1但没启用opcache.file_cache，或 CLI 环境未预热） - 大量使用
require_once加载小工具类，且这些类分散在不同子目录中，导致哈希表膨胀、查找变慢
require_once 和 require 性能差多少
实测数据（PHP 8.2 + OPcache 启用）显示：
- 单次调用：两者耗时差异在纳秒级，无实际意义
- 1000 次重复调用同一文件：
require稳定在 ~0.015ms/次；require_once约 ~0.022ms/次（多出约 47%） - 关键区别不在“执行”，而在“判断”——
require_once多了一次哈希查找 + 字符串比较，而require直接走已知路径加载字节码
所以，如果你能确保某个文件只被引入一次（比如在入口脚本顶部统一加载），直接用 require 更轻量；反之，若该文件可能被多个模块间接引用（如 Composer 自动加载前的手动补丁），require_once 的安全价值远大于那几微秒。
容易被忽略的兼容性陷阱
require_once 的“已加载”判定基于**完整解析后的绝对路径**，不是字符串匹配：
-
require_once 'foo.php'和require_once './foo.php'被视为两个不同文件（后者先做路径规范化，但早期 PHP 版本处理不一致） - 如果项目用了
chdir()，当前工作目录变化后，相对路径解析结果可能不同，导致重复加载或找不到文件 - Windows 下大小写不敏感，Linux 下敏感——
require_once 'Config.php'和require_once 'config.php'在 Linux 可能被当成两个文件，引发意外重载
真正麻烦的从来不是性能数字，而是路径解析逻辑和运行时环境的耦合——这点比“要不要加 _once”更值得花时间理清。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
