深度超6层易出问题，因DOM节点指数增长致性能下降、屏幕阅读器跳读层级，且需防循环引用栈溢出；PHP递归须显式深度控制与守卫；禁用innerHTML拼接，改用DocumentFragment或createElement；details仅适用浅层折叠菜单。
递归渲染 HTML 列表时，为什么深度超过 6 层就容易出问题
不是浏览器硬性限制，而是实际性能与可访问性双重衰减的临界点。DOM 节点数随深度指数增长，5 层嵌套可能生成 200+ 节点，低端设备上 layout 时间增加 30ms 以上；同时屏幕阅读器对超过 3 层的 ul 嵌套普遍跳读或丢失层级提示，aria-level 无法自动推导，必须手动补全。
- 每多一层
ul > li > ul，浏览器都要重新计算样式、生成匿名盒子、触发 layout —— 这些开销在移动设备上更敏感 -
ul ul ul这类无 class 的选择器极易误匹配，CSS 维护成本随深度平方级上升 - 服务端若未校验树结构（如存在
parent_id循环引用），前端递归会直接栈溢出，RangeError: Maximum call stack size exceeded
PHP 中 renderCategoryTree() 函数必须带深度参数和终止条件
不设 $depth 参数的递归函数，在面对脏数据时等于开闸放水。生产环境必须把深度控制作为第一道防线，而不是靠“数据应该干净”这种假设。
- 函数签名必须显式声明
function renderCategoryTree(array $tree, int $depth = 0): string，不能依赖默认值隐藏逻辑 - 开头加守卫：if (
$depth > 6) return ' - [max depth reached] '
- 每个递归调用必须传入
$depth + 1，且该值要用于生成 class（如"level-{$depth}"），避免用数组键或全局计数器 - 子节点渲染前先判空：
if (!empty($node['children'])) { ... }，防止空数组触发无效递归
JavaScript 递归拼接字符串时，innerHTML 是最大隐患
用 innerHTML += 在循环里拼 HTML，表面能跑通，实则埋下三重雷：事件绑定丢失、XSS 漏洞、DOM 重复解析。尤其当子菜单需绑定 click 或键盘事件时，innerHTML 重写会让所有监听器失效。
- 正确做法是构建 DocumentFragment 或数组 push 字符串，最后一次性
element.appendChild(fragment) - 若必须用字符串拼接，确保所有动态内容都经
textContent转义，或用document.createElement()+appendChild()替代 - React/Vue 等框架中，绝对不要在组件内用
innerHTML渲染递归结果，应交由虚拟 DOM 控制更新边界 - 错误示例：
el.innerHTML += `<ul>${renderChildren(children)}</ul>`—— 每次执行都重绘整个父容器
用 <details><summary> 替代深层 ul 嵌套的实际代价
它确实能规避大部分递归渲染问题，但并非银弹。浏览器对嵌套 <details> 的支持不一致，Safari 目前不支持 <details> 内再套 <details> 的键盘导航（Tab 键跳过子 summary），且无法用 CSS 精确控制展开箭头位置。
立即学习“前端免费学习笔记（深入）”；
- 可用场景：最多 3 层折叠菜单，且不要求键盘
↑↓←→全路径导航 - 不可用场景：需要 aria-expanded 同步控制、或子项需独立 hover 样式的复杂导航
- 折中方案：前两层用
<details>，第三层起切回ul+ JS 控制 display，用 class 区分层级而非依赖嵌套深度 - 必须补的 a11y：每个
<summary>都要带aria-controls指向对应<div>ID，否则屏幕阅读器无法建立关联
$depth 和 Set 去兜底——这层防御机制，往往被当成可选优化，直到线上报出 RangeError 才补。 
