最稳妥的方式是直接传参控制递归深度，即在函数签名中添加 $level 参数并配合常量 MAX_RECURSION_LEVEL 进行显式判断与递增；静态变量方式适用于无法修改调用方的场景，但需在 finally 块中严格自减；debug_backtrace() 性能差且不稳定，仅限临时调试；json_decode 的 $depth 参数与自定义递归无关。
直接传参控制递归深度：用 $level 参数最稳妥
PHP 本身不提供全局“递归层数开关”，但你可以在函数签名里加一个 $level 参数，每次调用时显式递增，并与预设上限比较。这是最可控、最易调试的方式。
- 定义常量如
MAX_RECURSION_LEVEL = 50，避免魔法数字 - 入口处立即判断：
if ($level >= MAX_RECURSION_LEVEL) { return null; } - 递归调用时必须传
$level + 1，漏写会导致限制失效 - 注意初始调用要传
0或1，保持计数起点一致
用 static $depth 跟踪：适合不想改调用方的场景
当无法修改所有调用点（比如封装在 SDK 或旧逻辑中），可用静态变量在函数内部维持深度状态。它不依赖外部传参，但必须严格配对自增/自减。
- 进入函数第一行写：
static $depth = 0; $depth++; - 检查是否超限：
if ($depth > 50) { $depth--; return null; } - 所有可能退出路径（包括异常、return、函数末尾）前都要执行
$depth-- - 多线程或并发请求下不安全，仅适用于单次请求生命周期
别碰 debug_backtrace()：性能开销大，只用于临时诊断
debug_backtrace() 能拿到当前调用栈，理论上可统计同名函数出现次数来限深。但它会显著拖慢执行速度，且结果不稳定——尤其在有 autoload、__call 等动态机制时。
- 每调用一次
debug_backtrace()可能增加 5–10ms 开销 - 返回数组结构随 PHP 版本变化，不能作为生产环境判断依据
- 仅建议在本地调试时临时加上，上线前必须删掉
- 替代方案：用
xdebug_get_function_stack()（需启用 Xdebug）更轻量，但仍不推荐长期使用
json_decode 的 $depth 参数不是递归函数的深度限制
容易混淆的一点：json_decode($json, true, $depth) 的第三个参数只影响 JSON 解析器自身的嵌套层级，和你自己写的递归函数完全无关。它不会约束你的 findPath() 或 traverseTree() 函数调用次数。
立即学习“PHP免费学习笔记（深入）”；
-
$depth是解析器内部计数器，单位是“对象/数组嵌套层数” - 你的函数递归 100 次，只要没调用
json_decode，就完全不受该参数影响 - 两者错误码也不同：
JSON_ERROR_DEPTH≠Fatal error: Maximum function nesting level - 后者才是真正的 PHP 执行栈溢出，由
xdebug.max_nesting_level（Xdebug）或zend.max_allowed_stack_size（PHP 8.3+）控制，但这些属于底层运行时配置，不应作为业务逻辑的限深手段
$depth，导致后续同请求内其他调用直接卡死**。务必把 $depth-- 放进 finally 块（PHP 7.1+）或每个 return 前。 
