JS长任务拆分落地关键在于建立“可观测—可决策—可验证”闭环：通过Performance面板日常诊断、CI中自动捕获TBT、新人速查表定位卡点、按任务类型提供标准化拆分模板、ESLint拦截隐性开销，并以INP和TBT为真实指标考核。
JS长任务拆分在团队落地，关键不是统一加setTimeout或硬推某套工具链，而是让开发者能自主识别、判断和响应真实卡顿场景。核心在于建立“可观测—可决策—可验证”的闭环，而不是靠规范文档压指标。
用 Performance 面板做日常诊断习惯
把性能分析变成开发流程的固定动作，而非上线前补救：
- 每次提交 PR 前，要求附上一次典型操作（如点击加载列表、切换 Tab）的 Performance 录制截图，重点标出是否有 >50ms 的 [Long Task] 红条
- 在 CI 流程中接入
PerformanceObserver，自动捕获构建后页面的长任务数量与总阻塞时间（TBT），超阈值则阻断发布 - 为新人配一份《三秒定位卡点》速查表：页面卡顿时，打开 DevTools → Performance → 点录制 → 操作复现 → 看 Scripting 区是否连续占满、Layout/Paint 是否频繁跳动
按任务类型定义拆分模板，不写自由发挥代码
避免每个同学都从零设计切片逻辑，提供可直接复用的模式：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
海量渲染类（如日历月视图、表格万行数据）：强制使用“可视区优先 + 天/行级单元 + requestIdleCallback”组合，封装成
renderInChunks(items, { unit: 'day', maxDuration: 2 }) -
启动初始化类（如 SDK 加载、非首屏预请求）：统一走低优队列，内置 fallback 机制——高优设备用
requestIdleCallback，低端机自动降级为setTimeout(..., 0) -
纯计算类（如本地搜索索引、JSON 转换）：禁止出现
for或while全量遍历；必须用chunkedProcess(data, { size: 300 })，每 chunk 后显式调用setTimeout让权
配套轻量优化纳入代码检查规则
拆分只是起点，很多卡顿来自隐性开销。把这些写进 ESLint 插件，自动拦截：
- 禁止在循环中读取
offsetHeight、getBoundingClientRect()—— 触发强制同步布局 - 插入多个节点必须用
DocumentFragment或element.append(...nodes)，禁用多次appendChild - 事件监听器默认延迟绑定，新组件需声明
lazyEvents: ['click', 'input']，由框架配合IntersectionObserver自动挂载
用 INP 和 TBT 替代“有没有拆”的主观判断
不考核“写了几个 setTimeout”，而看真实用户感知指标：
- 所有页面上线后自动上报 INP（Interaction to Next Paint），持续低于 200ms 才算达标
- 构建产物生成性能报告，对比上一版本 TBT 变化，上升超过 10% 需负责人说明原因
- 在测试环境模拟低端设备（CPU Throttling 4x slowdown + 2G 内存），跑通关键路径，确保切片粒度在真实设备上仍 ≤5ms
