用 debug_backtrace() + count() 获取当前递归深度最准确，因其直接反映真实栈帧数；max_recursion_depth 配置值不可靠，它统计全局函数嵌套总数而非单个递归深度；显式传 $depth 参数更可控但需规范使用。
直接看当前递归深度，用 debug_backtrace() + 层数计数最准，别依赖 max_recursion_depth 配置值——它只管函数嵌套总数，不反映你这段递归的真实深度。
怎么用 debug_backtrace() 实时抓当前递归层数
它返回的是完整调用链数组，你只需要数长度就行，比手动传 $depth 参数更客观（尤其适合你没改函数签名、又想快速诊断的场景）：
- 在递归函数开头加一行：
$trace = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS); $depth = count($trace); echo "Current depth: $depth\n"; -
DEBUG_BACKTRACE_IGNORE_ARGS能省掉参数序列化开销，避免大数组拖慢调试 - 注意：
count($trace)包含当前函数自身，所以输出的数字就是“从入口到这层”的真实栈帧数 - 如果想排除非业务函数（比如框架路由层），可以遍历
$trace过滤function键，只统计你关心的函数名出现次数
max_recursion_depth 配置值为什么不能当递归深度用
这个 ini 设置控制的是“整个 PHP 请求中所有函数嵌套调用的总层数”，不是单个递归函数的深度。它会把中间件、ORM 方法、模板引擎回调全算进去：
- 运行
echo ini_get('max_recursion_depth');通常返回100（PHP 8.5 默认），但实际业务递归走到 30 层就可能报错——因为前面已有 70 层被框架占了 - 修改
max_recursion_depth = 500只是放宽总限制，治标不治本；真正该做的是定位哪段递归失控 - 它无法告诉你“是
getCategoryDepth()嵌套了 80 层，还是renderTemplate()占了 60 层”，缺乏上下文
递归函数里显式传 $depth 参数的实操要点
这是最可控的方式，但容易写错。关键不是“要不要传”，而是“怎么传才不被覆盖”：
立即学习“PHP免费学习笔记（深入）”；
- 必须作为**必填参数**出现在函数定义里，例如：
function parseNode($node, $depth = 0)，不能靠默认值或全局变量补 - 每次递归调用时，显式加 1：
parseNode($child, $depth + 1)—— 别写$depth++或$depth += 1，PHP 中这不会影响下一层 - 设阈值要留余量：
if ($depth > 50) { throw new RuntimeException("Recursion too deep at {$node['id']}"); }，50 是安全起点，远低于 100 的全局限制 - 如果函数被多处调用，入口处统一初始化
$depth，别让调用方自己决定从 0 还是 1 开始，否则日志对不上
生产环境别用 debug_backtrace() 暴力轮询
它每次调用都要遍历整个栈，开销不小。真要监控，得按需开关：
- 开发阶段可全局开：
register_shutdown_function(function () { if (error_get_last() && str_contains(error_get_last()['message'], 'Maximum function nesting level')) { var_dump(debug_backtrace()); } }); - 生产环境建议只在特定业务路径启用，比如支付验证前加
if (defined('DEBUG_RECURSION') && DEBUG_RECURSION) { ... } - 更轻量的替代：用
debug_print_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 3)限制只打最顶上 3 层，够定位问题又不拖慢 - 真正高危的递归（如无限循环解析 JSON），优先用 while 循环重写，而不是调高
max_recursion_depth
递归深度不是配置出来的，是跑出来的。同一段代码，在 CLI 和 FPM 下深度可能差 20 层；开了 Xdebug 后，debug_backtrace() 返回的数组长度会变长——这些细节不实测根本不知道。
