“假死”是因不可变对象嵌套操作引发的无限递归计算，表现为CPU满载、内存暴涨、无报错但响应停滞；需通过调用栈分析、深度限制、环检测和路径校验快速定位与收口。
这类“假死”不是进程卡住或线程阻塞，而是代码逻辑在不可变对象的嵌套结构中反复创建新副本、无限递归展开或误判终止条件，导致 CPU 持续满载、内存暴涨、响应停滞——表面无报错，实则陷入无效计算循环。
看调用栈是否出现重复类型展开
打开浏览器 DevTools 或 IDE 调试器，在疑似卡顿时打断点或抓取堆栈（如 Chrome 的 Performance 面板录制后查看 JS Call Tree）：
- 若看到类似
mapKeys → deepMerge → mapKeys → deepMerge → …这样的交替递归调用，说明工具函数在处理嵌套不可变结构时未设深度守卫 - TypeScript 编译阶段报
Excessive stack depth或运行时报Maximum call stack size exceeded，基本可锁定是泛型/递归类型 + 不可变操作双重叠加所致 - 特别留意
immer的produce内部、lodash/fp的set/update、或自定义的deepSet工具——它们对深层路径（如'a.b.c.d.e'）做不可变更新时，若路径过长或结构存在环引用，极易触发隐式无限展开
查不可变操作是否在分支逻辑中隐式递归
常见于“根据条件决定是否继续嵌套”的场景，例如配置合并、表单 schema 动态生成、权限树折叠等：
- 代码写成：
if (node.children) return { ...node, children: node.children.map(transform) }，但transform又无条件调用自身，且未检查node是否已处理过（如缺少processed标记或缓存键） - 使用
Immutable.Map.setIn(['a','b','c'], value)时，若传入的 key 数组本身来自另一层嵌套计算（如getKeysFromSchema(schema)），而该函数又依赖schema的子字段递归推导，就可能形成逻辑闭环 - 检查所有
reduce/flatMap/map嵌套调用，确认其 accumulator 或返回值没有意外复用原始不可变对象的深层引用（如误将original.get('items')直接 push 到新数组）
验数据结构是否存在隐式环或歧义路径
不可变对象本身不允环，但“描述结构”的路径或 schema 可能构造出逻辑环：
- 比如权限节点定义中：
{ id: 'A', parent: 'B' }和{ id: 'B', parent: 'A' }，遍历时未做 visited 集合去重，就会无限跳转 - 路径字符串拼接错误：本应为
`${prefix}.${key}`，却写成`${prefix}.${prefix}.${key}`，导致路径指数级膨胀（a → a.a → a.a.a…） - JSON Schema 中
$ref循环引用未被解析器截断，后续用它生成表单字段时，工具库反复展开同一 definition，CPU 占用持续 100%
快速验证与收口建议
不用等线上爆发，本地就能定位：
- 在可疑函数入口加简单计数器：
let depth = 0; function walk(node) { if (++depth > 20) throw new Error('Too deep'); ... } - 对关键不可变操作加 shallow 检查：
if (original === next) return original;防止无变更重复克隆 - 把深层路径访问（如
obj?.a?.b?.c?.d?.e）提前解构并校验：const { a } = obj || {}; const { b } = a || {}; …，避免空值穿透引发冗余计算 - 涉及多层条件分支的累加逻辑（如 reduce 多个嵌套 filter/map），改用显式 for 循环 + break 控制流，比链式调用更可控、易调试
