JS长任务拆分本身不报错，常见错误源于拆分不当导致的逻辑错误、状态不一致或时序异常：如undefined访问因DOM卸载、回调重复触发、递归失控、组件卸载后更新状态等，需结合执行模型与生命周期理解并防范。
JS 中长任务拆分本身不会直接报错，所谓“常见报错”其实是拆分不当或误用异步机制后，引发的 逻辑错误、状态不一致、时序异常 所导致的典型现象。记它不靠死背，而要理解每条信息背后的执行模型和常见陷阱。
Uncaught TypeError: Cannot read property 'xxx' of undefined（最常出现）
说明：任务被拆开后，原同步流程中“理所当然存在”的对象/变量，在后续微任务或宏任务中已失效（如 DOM 被移除、组件已卸载、闭包引用丢失）。
- 检查拆分点是否在 DOM 操作后立即返回，但后续回调还试图访问该 DOM 元素
- React/Vue 等框架中，确认组件是否还在挂载状态（例如用
isMounted或useEffect cleanup清理） - 避免在
setTimeout(fn, 0)或Promise.resolve().then()中直接使用外部作用域里可能被回收的引用
Callback was already called / Promise resolved multiple times
说明：手动拆分任务时重复触发了回调或 resolve，比如在事件监听 + 定时器组合场景下，未做防重处理。
- 对关键回调加
if (called) return; called = true;标记 - 用
Promise封装时，确保只调用一次resolve或reject（原生 Promise 会静默忽略多次调用，但业务逻辑可能出错） - 警惕
addEventListener绑定多次却没removeEventListener
Maximum call stack size exceeded（递归拆分失控）
说明：本想用 setTimeout 或 queueMicrotask 拆分循环，却写成同步递归调用，或未设终止条件。
- 拆分 for 循环时，别写
processNext(); processNext();这种无延时递归 - 正确做法是每次只处理一部分数据，再用
setTimeout(processNext, 0)推入下一轮 - 记录当前处理索引或剩余数据长度，确保终有出口
State updated after component unmounted（React 特有提示）
说明：异步任务完成时，组件已销毁，但仍尝试 setState，虽不崩溃但浪费资源且可能掩盖真实问题。
- 函数组件中，在
useEffect的清理函数里设一个isMountedRef.current = false - 异步回调开头加判断：
if (!isMountedRef.current) return; - 更推荐用
AbortController配合fetch或自定义逻辑做取消（现代方案）
