主线程卡顿源于长任务独占JS引擎，拆分需主动让座：用宏任务交还控制权、requestIdleCallback利用空闲时间、Web Worker转移CPU密集任务。
你可以把浏览器的主线程想象成一个单窗口办事大厅——只有一名工作人员（JS 引擎），所有事情都得排队等他处理：用户点按钮、页面动画、渲染新内容、执行你的代码……全都排在一条队里。
为什么“长任务”会卡住整个页面？
如果某位“办事人”（比如一段循环 10 万次的 JS 代码）一进来就占着窗口不走，一口气干 200ms，那后面所有人（包括动画帧、鼠标点击、滚动响应）都得干等。浏览器每秒要画 60 帧，每帧只有约 16ms；一旦单个任务超 50ms，就被标记为“长任务”，用户立刻感觉卡顿、点不动、滚不动。
拆分不是“切几刀”，而是“主动让座”
真正的拆分，不是把大循环改成十个小循环，而是让 JS 主动说：“我先干 2ms，剩下的下次再干——您先办别的事。”关键靠三类“让座机制”：
- 宏任务（如 setTimeout）：像喊一声“我歇会儿！”，立刻把控制权交还给浏览器，让它有机会渲染、响应点击，下一轮事件循环再继续
- 微任务（如 queueMicrotask）：适合批内快速衔接，比如“处理完这 100 条数据后，马上格式化它们”，但它不释放渲染权，不能用来防卡顿
- requestIdleCallback：最聪明的策略——它不抢时间，专挑浏览器空闲时（比如动画刚结束、用户没操作的间隙）才干活，还会告诉你“只剩 1.8ms 了，快收工”，自动控制每片 ≤2ms
光拆不行，还得配合“不反复折腾”
拆完只是第一步。比如渲染列表，如果每条都单独 appendChild，浏览器会反复重排重绘（layout thrashing）；正确做法是用 DocumentFragment 先攒一堆节点，再一次性插进去。再比如日历渲染，按“天”拆比按“事件”拆更合理——因为 DOM 结构天然以天为单元，跨日连线也得等相关日期都就位才能画，逻辑和结构对齐了，拆起来才不乱。
什么时候该换地方干？
如果任务本身特别吃 CPU（比如解析百万行日志、做图像计算），哪怕切成小片，也在主线程上抢资源。这时候就得请“外援”——Web Worker，在后台线程里默默干活，主线程全程不沾手，只等结果。这不是拆分，是“转岗”。
