js长任务拆分需标准化识别、模板化拆解、状态硬约束及流程化验证。一要performance面板标注>50ms任务与同步布局；二按dom渲染、启动初始化、纯计算三类场景套固定模板；三强制闭包外状态管理、批量dom更新、中断响应；四通过本地护栏、pr录制对比、ci扫描确保达标。
JS 长任务拆分不是加个 setTimeout 就算完成，而是要让主线程在每帧内有足够时间处理渲染、输入和动画。团队落地的关键，在于把“识别—拆解—验证”变成可执行、可检查、可传承的规范动作。
一、长任务识别必须标准化
禁止凭经验或肉眼判断“好像卡了”。所有性能问题上报和 PR 评审，必须附带可复现的 Performance 面板录制片段（时长 ≥3 秒），并标注以下三项：
- 筛选出所有 >50ms 的 Main 线程任务，特别标出连续堆叠的 Scripting 区域
- 定位是否含强制同步布局操作（如
offsetTop、getComputedStyle、clientWidth） - 检查调用栈中是否存在未降级的
requestIdleCallback（无timeout）、深层Promise.then链、或误用setTimeout(fn, 0)做微任务
二、拆分策略按场景写死为模板
团队不接受自由发挥式拆分。以下三类高频场景，直接对应固定写法模板，写进 ESLint 自定义规则和代码片段库：
-
海量 DOM 渲染（如万级列表、日历月视图）：必须用
requestIdleCallback+ 单位切片（如“每轮 ≤2ms”或“每天/每页为单位”），DOM 插入统一走DocumentFragment，禁止循环内el.appendChild -
启动期初始化（如 SDK 加载、非首屏数据预取）：必须区分同步项（根节点挂载、路由注册）与低优项；后者统一走
requestIdleCallback({ timeout: 2000 })，降级逻辑内置在封装函数中 -
纯计算密集型（如 JSON 解析、数组聚合）：必须用
chunked分片（如每批 200–300 条），每批结尾调用setTimeout(() => {}, 0)让出控制权；禁止出现无中断的for或while大循环
三、状态管理与副作用约束成硬规
拆分后逻辑断裂、中间状态丢失、DOM 反复重排，是比不拆更糟的结果。以下为强制条款：
- 所有分片任务必须将索引、缓存结果、中断标志等存在闭包外对象中（如
state = { index: 0, items: [], done: false }），禁用仅依赖函数参数或局部变量的“裸递归” - 批量 DOM 更新必须收口：拆分期间只收集变更（字符串拼接 /
DocumentFragment.append()），最终一次性提交；禁止在子任务中调用el.innerHTML = ...或多次el.style.color = ... - 监听用户中断信号：滚动、点击、键盘输入发生时，需通过
AbortController.signal或布尔标记位主动退出非关键后续分片
四、验证与准入机制嵌入开发流程
不验证的拆分等于没做。团队要求：
- 本地开发环境默认开启性能护栏：当单次 JS 执行 >80ms 或内存增长 >2MB，控制台输出警告并打印调用栈
- PR 提交前必须运行本地 Performance 录制对比：新旧逻辑各录一次，重点比对 INP（Interaction to Next Paint）指标变化和长任务数量增减
- CI 流程中加入自动化检查：扫描源码，拒绝出现未包裹分片逻辑的
for (let i = 0; i 、未设 <code>timeout的requestIdleCallback、以及循环内触发重排的属性读取
规范不是限制，而是降低每个人做对事的门槛。把“该不该拆”变成“怎么拆”，把“感觉不卡”变成“指标达标”，团队才能真正稳住体验底线。
