大数据遍历卡顿主因是单次脚本执行超50ms被标记为长任务，应按耗时切片至1–5ms/块，结合performance.now()、硬件信息动态调批大小，并依场景选用requestAnimationFrame、queueMicrotask或requestIdleCallback调度，DOM更新需攒批，辅以AbortController和虚拟滚动优化。

大数据遍历卡顿，本质不是数据多，而是单次脚本执行太久——超过 50ms 就会被浏览器标记为长任务，用户立刻感知卡死。拆分目标不是缩短总耗时，而是把每一块控制在 1–5ms（保守可放宽至 10–30ms），给渲染、输入、动画留出空隙。

按执行时间切片，别按条数硬分

固定“每次处理 100 条”在不同设备上效果差异很大：低端机可能超 20ms，高端机又浪费空闲时间。更合理的方式是：

• 用 performance.now() 在每块开始和结束打点，真实测量耗时
• 初始批大小参考 navigator.hardwareConcurrency 和 navigator.deviceMemory（如 2 核/2GB 内存 → 初始设 30 条）
• 连续两轮超 2ms，自动将批大小 ×0.7；低于 0.8ms 可适当放大，但上限不超 200 条
• 始终检查 deadline.timeRemaining() > 1（requestIdleCallback 场景）或预留 ≥1ms 给渲染

选对调度时机：宏任务、微任务、帧对齐各司其职

不同场景下，让出控制权的“位置”决定流畅度：

Java注释规范Skills

当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。

下载

• 含 DOM 渲染的任务（如列表插入）：优先用 requestAnimationFrame，天然对齐 16ms 帧周期，滚动/动画不撕裂
• 纯计算无 DOM（如 JSON 转换、校验）：用 setTimeout(, 0) 或 queueMicrotask，确保微任务清空后再进下一宏任务
• 后台低优任务（如日志聚合、缓存预热）：用 requestIdleCallback({ timeout: 2000 })，空闲时跑，超时强制执行防饥饿

状态不能丢，DOM 更新要攒批

拆分后最常犯的错是状态重置或 DOM 频繁触发重排：

• 当前索引、中间结果、中断标志必须存在闭包或外部对象里，别靠局部变量重算
• 拆分期间只做数据处理，DOM 插入统一收尾：用 document.createDocumentFragment() 批量塞入，或拼接 HTML 字符串后一次性赋值 innerHTML
• 避免在循环中读取 offsetHeight、getBoundingClientRect() 等，它们会强制同步 layout，直接拖垮分片收益

配合轻量级优化，防止“拆了还卡”

单靠切片不够，隐性开销常成瓶颈：

• 用户滚动或点击时，用 AbortController 或布尔标记提前退出非关键后续分片
• 禁用内联样式动态计算，改用 CSS class 控制状态
• 对万级以上数据，考虑降级为虚拟滚动——只渲染可视区 ±5 行，彻底绕过全量遍历
• 用 Chrome Performance 面板验证：Scripting 区间应呈“锯齿状”短条，而非连续红块；INP（Interaction to Next Paint）指标应稳定在 200ms 内

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南