高频递归深拷贝会同步阻塞主线程，导致卡顿或白屏；实测耗时取决于嵌套深度、可变对象数及引用复杂度，如5000子对象三层嵌套配置可达8–15ms；每秒20次即占用160–300ms，p95延迟超100ms；常见于useeffect、computed等高频重入场景；应改用结构扁平化、immer、web worker或延迟触发替代。
高频递归深拷贝在大规模单页应用中不是“慢一点”的问题，而是会直接卡住主线程、拖垮交互响应。它不产生锁竞争，但靠纯计算密集型操作吃满 CPU 时间片，本质是同步阻塞——浏览器主线程没空处理渲染、输入、定时器，用户立刻感知为卡顿或白屏。
看实际耗时：别信理论，要测真实数据结构
深拷贝开销不取决于元素个数，而取决于嵌套深度、可变对象数量、引用图复杂度。例如：
- 一个含 5000 个子对象的三层嵌套配置（每个子对象含 dict + list + custom class），
copy.deepcopy在 Chrome V8 下实测可能达 8–15ms； - 若该操作每秒触发 20 次（如表格实时筛选+排序+高亮联动），主线程每秒被独占 160–300ms，P95 响应延迟必然突破 100ms；
- 更危险的是，它常藏在
useEffect、computed或事件回调里，看似“只执行一次”，实则随用户操作高频重入。
识别隐性阻塞点：三类典型误用场景
很多团队以为“只要没加锁就没事”，却忽略了 JavaScript 单线程模型下，长任务 = 阻塞：
-
状态派发前无脑深拷贝：比如 Redux Toolkit 的
createReducer已默认使用 Immer，再对 payload 手动deepcopy属于双重冗余； - 虚拟滚动中每次滚动都深拷贝整个数据源：其实只需浅拷贝 + 按需 patch 可见区域项；
- 表单联动导致嵌套对象反复重建：如修改一个字段就深拷贝整个 formState，而 formState 含大量未变更的附件元数据、历史快照等。
量化评估方法：用 Performance API 精准抓包
不要依赖 console.time。在关键路径插入：
const markStart = performance.now();
const safeCopy = JSON.parse(JSON.stringify(largeData)); // 或 deepcopy
const markEnd = performance.now();
console.log(`Deep copy cost: ${(markEnd - markStart).toFixed(2)}ms`);
更进一步：
- 用 Chrome DevTools 的 Performance 面板 录制用户典型操作流，筛选出耗时 >5ms 的
FunctionCall，查看调用栈是否落入deepcopy或其依赖（如memo字典操作、类型检查）； - 监控 Task Duration 分布：若 10ms+ 的长任务占比超 15%，且其中多个堆栈含
copy、traverse、clone关键字，即为高危信号； - 配合
Long Tasks API上报线上真实阻塞数据：navigator?.locks?.query()?不适用，但performance.getEntriesByType('longtask')可捕获主线程连续占用 ≥50ms 的任务。
替代方案比优化深拷贝更有效
真正降低阻塞，不是让 deepcopy 快 20%，而是让它根本不出现在主线程：
-
结构扁平化 + ID 引用：把深层嵌套转为 Map
+ 数组存 ID，复制仅需 [...idArray]； -
不可变更新库：用
immer.produce替代全量深拷贝，只代理变更路径，其余共享内存； -
Worker 搬运：将深拷贝逻辑移至 Web Worker，主线程只传
postMessage，避免任何 JS 执行阻塞； -
延迟/节流触发：对非即时反馈场景（如导出预处理），用
setTimeout(..., 0)或queueMicrotask让出当前帧，或合并多次变更再批量处理。
