长任务拆分核心是让主线程喘息，将阻塞渲染的长逻辑拆为可中断小单元；需先用performance面板确认>50ms长任务，再按纯计算、渲染联动等场景选web worker、requestanimationframe等策略，并守住契约不变、状态可控、错误清晰三底线。
长任务拆分不是为了“切代码”而切，而是为了让主线程喘口气——把原本卡住渲染、阻塞交互的一整块逻辑，变成多个可中断、可调度的小单元。关键不在拆得多细，而在拆得恰到好处：既释放主线程，又不引入过多调度开销。
识别哪些任务真该拆
别一上来就重构。先确认它确实是长任务：
- 用 Chrome DevTools 的 Performance 面板 录制操作，看是否出现 >50ms 的主线程连续执行块（标红的 “Long Task”）
- 用户反馈“点不动”“滚动卡顿”“输入延迟”，且问题复现稳定
- 函数内部含大循环（如遍历上万条数据）、深度递归、同步 DOM 批量读写或复杂计算（如矩阵运算、JSON 解析+遍历）
按场景选对拆法
没有银弹，不同任务类型匹配不同策略：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
纯计算型（无 DOM 依赖）：扔进
Web Worker。例如数据聚合、加密解密、图像处理——完全隔离主线程 -
需配合渲染节奏（如动画、滚动联动）：用
requestAnimationFrame。每帧只处理一小批，自然对齐 60fps -
普通 UI 更新或异步流程控制：用
setTimeout(fn, 0)或queueMicrotask。让出当前任务队列，触发重排/重绘机会 -
大数据集逐批处理（如渲染 10 万条列表）：先
chunkArray(data, 200)分块，再用async/await + setTimeout逐块插入或更新
重构时守住三个底线
拆完代码不能更难懂、更难测、更难维护：
- 保持输入输出契约不变：原函数接收什么、返回什么、抛什么错，重构后必须一致。调用方无需改一行
- 状态必须可控移交：如果任务有中间状态（如累计计数、缓存结果），不要藏在闭包里；显式传入/传出上下文对象
-
错误边界要清晰：某一块失败，是跳过继续？还是中止整个流程？用
try/catch明确包裹每块，并提供统一回调或 Promise reject 处理路径
一个真实可抄的分块处理模板
比如你要遍历 5 万条记录做格式转换并批量写入 DOM：
function processLargeList(items, batchSize = 200) {
const chunks = chunkArray(items, batchSize);
let index = 0;
function processNext() {
if (index >= chunks.length) return;
const chunk = chunks[index++];
const frag = document.createDocumentFragment();
for (const item of chunk) {
const el = document.createElement('div');
el.textContent = transformItem(item);
frag.appendChild(el);
}
document.getElementById('list').appendChild(frag);
// 让出主线程，等下一帧
requestAnimationFrame(processNext);
}
processNext();
}
这里没用 setTimeout 是因为 DOM 插入需配合渲染；没用 Promise.all 是为避免一次性创建全部元素压爆内存；chunkArray 是纯函数，可独立测试。
