PHP无内置包含深度限制，所谓“包含太深报错”实为max_execution_time超时、内存耗尽或Xdebug的xdebug.max_nesting_level限制所致；include_path仅影响查找路径，与深度无关。
php.ini 中 include_path 不影响包含深度，真正起作用的是 max_execution_time 和递归逻辑本身
PHP 本身没有“文件包含深度限制”这个内置配置项。所谓“包含太深报错”，实际是递归包含触发了超时、内存耗尽，或人为用 include/require 写出了死循环。比如 A.php 包含 B.php，B.php 又无条件包含 A.php，就会无限递归——这时不是被“深度限制”拦住，而是 PHP 进程被 max_execution_time 终止，或抛出 Fatal error: Maximum function nesting level of 'X' reached（这是 Xdebug 开启时的提示，非原生 PHP 行为）。
- 原生 PHP 不检查包含层数，只管执行；Xdebug 的
xdebug.max_nesting_level才会限制函数调用栈深度（含include调用） -
include_path只控制查找路径，和“深度”完全无关 - 真正卡住你的，往往是没做循环引用检测，或没设
realpath()去重
如何安全地实现多层包含而不崩 —— 推荐用 get_included_files() 做去重
如果你在写插件系统、模块加载器或模板嵌套机制，需要支持多层 include 但又怕重复载入或循环，最轻量靠谱的做法是在包含前查表：
function safe_include($file) {
$abs = realpath($file);
if ($abs && in_array($abs, get_included_files())) {
return false; // 已包含过，跳过
}
return include $file;
}
-
get_included_files()返回当前请求中所有已被include/require的绝对路径数组，开销极小 - 必须用
realpath()标准化路径，否则./a.php和a.php会被视为两个文件 - 不要依赖
__FILE__或debug_backtrace()做层数计数——它们不可靠且拖慢性能
Xdebug 报 Maximum function nesting level？关掉它或调高 xdebug.max_nesting_level
这个错误不是 PHP 崩了，是 Xdebug 主动截断了调用栈。开发环境常见，上线环境通常不装 Xdebug，所以别误以为这是生产问题。
- 临时关闭：命令行加
-d xdebug.mode=off，或注释 php.ini 中zend_extension=xdebug.so - 调高限制：在 php.ini 中设
xdebug.max_nesting_level = 500（默认 256），够大多数嵌套场景用 - 注意：调太高可能掩盖真实递归 bug，建议先用
safe_include()+ 日志定位哪两个文件在互相包含
用 opcache.enable=1 和 opcache.validate_timestamps=0 缓解重复包含开销
即使做了去重，频繁 include 同一文件仍会走文件系统 stat 检查。OPcache 可以跳过这步，尤其适合模板类多层 include 场景。
立即学习“PHP免费学习笔记（深入）”；
- 确保
opcache.enable=1（CLI 模式默认关，需显式开启） - 开发期可设
opcache.validate_timestamps=1，上线后切为0避免每次检查修改时间 -
opcache.revalidate_path=0也能减少符号链接解析开销，对include_path复杂的项目有帮助
真正的防溢，不在改某个“深度参数”，而在切断循环源头、用好 get_included_files()、关掉干扰项（如 Xdebug 的过度保护）、再让 OPcache 拦住重复加载。路径越动态，越要早做 realpath 归一化——这点容易被忽略，但一漏就进坑。
