适合，但需满足轻量、可中断、不触发重排等前提；适用于删除临时节点、合并文本节点等后台维护，禁用深度遍历或读取offsetHeight等阻塞操作。
requestIdleCallback 适合做 DOM 清理吗？
适合，但有严格前提：清理操作必须轻量、可中断、不依赖即时响应。它不是 setTimeout 的替代品，而是专为「用户无感知的后台维护」设计的——比如删掉 data-temp="true" 的临时节点、合并相邻的纯文本节点、移除已标记 __isStale 的冗余 span。一旦你试图在回调里执行深度遍历或强制 layout（如读取 offsetHeight），就会拖慢空闲窗口，甚至被浏览器直接丢弃任务。
怎么注册一个安全的清理任务？
关键不是“注册”，而是“控制执行节奏”和“避免重入”。requestIdleCallback 不保证调用，也不排队，重复调用会覆盖前一个。常见错误是每次编辑后都调用，结果只留下最后一次清理逻辑。
- 用
let cleanupHandle = null缓存上一次句柄，调用前先cancelIdleCallback(cleanupHandle) - 回调函数必须检查
deadline.timeRemaining() > 1，低于 1ms 就中止并重新调度 - 清理范围要限定：只处理最近 50 个新增/修改过的节点（靠编辑器自身维护的
dirtyNodesSet） - 不要在回调里修改 document.body 或触发样式重排；优先用
node.remove()而非innerHTML = ''
示例：
function scheduleCleanup() {
if (cleanupHandle) cancelIdleCallback(cleanupHandle);
cleanupHandle = requestIdleCallback(
(deadline) => {
while (dirtyNodes.size && deadline.timeRemaining() > 1) {
const node = dirtyNodes.values().next().value;
if (node && node.dataset.temp === 'true') node.remove();
dirtyNodes.delete(node);
}
if (dirtyNodes.size) scheduleCleanup(); // 剩余继续
},
{ timeout: 2000 } // 防止饿死，2s 内必须执行一次
);
}
为什么清理后 DOM 还闪烁或光标跳动？
这是最常被忽略的副作用：清理操作意外影响了编辑器的 selection 或 focus 状态。尤其当删除的是光标所在节点的兄弟元素时，浏览器可能重置 window.getSelection() 位置。
立即学习“前端免费学习笔记（深入）”；
- 清理前保存当前光标位置：
const sel = getSelection(); const range = sel.getRangeAt(0).cloneRange(); - 清理后手动恢复：
sel.removeAllRanges(); sel.addRange(range); - 更稳妥的做法：跳过所有包含
contenteditable="true"祖先的节点，或跳过document.activeElement的子树 - 避免清理
br、zwnj这类用于光标定位的“幽灵节点”——它们没内容，但对编辑体验至关重要
Chrome 120+ 和 Safari 17.4 的兼容性陷阱
Safari 目前仍不支持 timeout 选项，传了会被静默忽略；Chrome 120 起对超时任务的调度更激进，可能连续两次空闲回调之间间隔长达 100ms（尤其在页面后台时）。这意味着不能假设“注册即执行”。
- 降级方案：用
setTimeout(() => {}, 0)包裹清理逻辑，作为兜底（但仅限简单删除，不可用于 layout 操作） - 检测是否可用：
if ('requestIdleCallback' in window)，否则直接走兜底路径 - 不要依赖
deadline.didTimeout做主逻辑分支——Safari 返回undefined，Chrome 有时不准确
真正难的不是写清理代码，是判断“哪些 DOM 真的冗余”。编辑器内部状态（如撤销栈、语法高亮缓存、IME 输入状态）和 DOM 结构之间的映射，稍有错位就会把有效节点当垃圾清掉。这个边界得靠编辑器自己定义，requestIdleCallback 只负责给它一个不卡顿的执行时机。
