dom深度超6层确为可测卡顿根源，chrome devtools中layout耗时突增、node.depth≥7即属高危，每增1层引发样式继承与布局上下文开销非线性上升，移动端fcp常延迟300ms以上。
DOM深度超过6层时，渲染卡顿不是错觉而是可测事实
Chrome DevTools 的 Performance 面板里 Layout 阶段时间突然拉长，大概率不是节点总数多，而是真实 node.depth ≥ 7。浏览器每增加一层嵌套，就要多做一次样式继承、属性回溯和布局上下文创建——这不是线性增长，是指数级加重。移动端低端设备上，depth ≥ 8 常导致 FCP 延迟 300ms 以上。
别只数源码里的 <div> 层数：SSR 渲染生成的 <code><div data-v-xxx>、空 wrapper、Vue 的默认根节点，全部计入深度。右键 Elements 面板任意节点 → <code>Show DOM properties → 直接看 depth 值，这才是真实数据。
递归组件中，数据结构比写法更致命
Vue 报 max stack size exceeded 或 React 渲染空白，90% 不是组件写错了，而是接口返回的是扁平数组（带 parentId），没提前转成树形结构就直接喂给递归组件。
- 必须先做一次扁平转树：用
Map缓存所有节点，键为id；遍历一次，对每个节点查parentId对应的父项，把当前节点push到父项的children数组 - 边界要统一处理：
parentId是0、null、''还是undefined？建议全转成undefined再判断根节点 - 转树逻辑绝不能放在递归组件内部——否则每层都重跑一遍，性能是
O(n²)级崩盘
服务端 PHP 递归模板必须带深度守卫
没有 $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'])) { ... }，防止空数组触发无效递归
原生 JS 动态拼接菜单时，innerHTML 是最大隐患
用 innerHTML += 在循环里拼 HTML，表面能跑通，实则埋下三重雷：事件绑定丢失、XSS 漏洞、DOM 重复解析。尤其当子菜单需绑定 click 或键盘事件时，innerHTML 重写会让所有监听器失效。
- 可靠方案只有两个：
DocumentFragment或document.createElement()+appendChild() - 错误示例：
el.innerHTML += `<ul>${renderChildren(children)}</ul>`—— 每次执行都重绘整个父容器 - 若必须用字符串拼接，确保所有动态内容都经
textContent转义，或直接用createElement替代
.page .header .nav .item a 这种四层嵌套，浏览器照样从每个 a 往上逐层验证，性能损耗不减。真正要改的，是类名设计和样式作用域，不是单纯删 div。
