线上环境必须用代码层控制递归深度，禁用xdebug.max_nesting_level等全局配置；推荐显式$depth参数+常量阈值（如MAX_RECURSION_DEPTH=50），递归前判断并安全返回；json_decode深度与业务递归无关，需分别控制；关键路径优先采用迭代替代递归。
线上环境不能靠 php.ini 或 xdebug.max_nesting_level 限制递归深度
线上环境必须用代码层控制，而不是依赖 xdebug.max_nesting_level 或 max_execution_depth 这类全局配置。Xdebug 在生产环境通常被禁用，且修改 php.ini 需要重启 PHP-FPM，无法动态应对不同业务场景；更重要的是，这类配置是进程级的，一个接口的深层递归可能拖垮整个 worker 进程。
推荐用带 $depth 参数的显式计数器 + 常量阈值
这是最可控、最易测试、也最容易排查问题的方式。所有递归入口函数都应接受一个 $depth 参数，默认从 0 开始，并在每次递归调用时加 1。
-
define('MAX_RECURSION_DEPTH', 50)放在配置文件或入口脚本顶部，统一管理阈值 - 每次递归前判断
if ($depth >= MAX_RECURSION_DEPTH) { return null; }，不抛异常（避免未捕获中断流程） - 对返回值做空检查，比如树形遍历中跳过超深节点，而非让整个请求失败
- 不要用静态变量（
static $count）——并发请求下会互相污染
json_decode 的深度限制和递归函数不是一回事
别混淆 json_decode($json, true, $depth) 的 $depth 参数和你自己写的递归函数深度控制。前者只管 JSON 解析器内部嵌套层级，后者是你业务逻辑里的调用栈层数。即使你把 json_decode 的深度设成 1000，你自己的 buildMenuTree() 递归调用仍可能在第 51 层就爆栈。
-
json_decode超深时返回null，且json_last_error()会是JSON_ERROR_DEPTH - 你的递归函数超深时，PHP 报的是
Fatal error: Maximum function nesting level of 'X' reached（如果 Xdebug 开着）或直接segfault（Xdebug 关闭时更危险） - 两者都要单独控制，不能互相替代
迭代替代方案在关键路径上更值得考虑
如果你的递归函数处理的是用户输入的树形结构（比如菜单、评论嵌套、权限规则），强烈建议直接改用迭代。递归深度控制只是“止血”，迭代才是根治。
立即学习“PHP免费学习笔记（深入）”；
- 用
$stack = [$rootNode]模拟调用栈，while (!empty($stack))循环处理 - 每层只压入子节点，不产生新函数帧，彻底避开栈限制
- 配合
yield可进一步降低内存峰值，尤其适合流式输出场景 - 上线前用真实数据压测：构造 200 层嵌套 JSON →
json_decode→ 迭代构建树，确认无超时或 OOM
真正容易被忽略的，是递归深度阈值和实际数据分布之间的 gap——设了 50 层，但某次上游传来的配置恰好有 49 层嵌套，再加一层业务逻辑就踩线。所以阈值要留余量，且必须配合日志记录临界调用（比如 if ($depth === MAX_RECURSION_DEPTH - 5) error_log("near recursion limit: $depth")）。
