scheduler.yield()尚未被标准化，截至2024年主流浏览器均不支持；Chrome曾于2022年实验性引入后已于v108移除，当前可靠替代方案仅有setTimeout或postMessage实现宏任务让出。
HTML 中根本没有 scheduler.yield()
浏览器当前（截至 2024 年）**不支持** scheduler.yield() 这个 API。它从未被标准化，也未在任何主流浏览器中实现。你看到的可能是混淆了以下几种情况：
- Chrome 曾在 2022 年短暂实验过
self.scheduler.yield()（Origin Trial 阶段），但已于 Chrome 108+ 彻底移除 - 某些文章或 demo 把
await scheduler.wait(0)（非标准、已废弃）或await new Promise(r => setTimeout(r, 0))误称为 “yield” - 与 Deno、Node.js 的
process.nextTick()或queueMicrotask()混淆
真正能主动让出主线程的可靠方法只有两个
目标是：在长任务中插入“断点”，让浏览器有机会处理输入事件（如 click、keydown）、重绘、滚动等。可行手段非常有限且有明确语义差异：
-
await new Promise(r => setTimeout(r, 0))：强制切到下一个宏任务（macrotask）轮次，保证输入事件、resize、scroll 等已入队的事件被处理。开销略大，但最稳妥 -
await queueMicrotask(Promise.resolve())不行 —— 微任务不会让出控制权给事件循环；必须用setTimeout或postMessage -
await new Promise(r => postMessage('', '*', [r]))是更轻量的宏任务切换方式（无定时器延迟），但需注意postMessage在 iframe 或 worker 中行为不同
示例：防止输入卡顿的长计算分片
async function processLargeArray(data) {
for (let i = 0; i < data.length; i++) {
doHeavyWork(data[i]);
// 每处理 100 项，让出主线程
if (i % 100 === 0) await new Promise(r => setTimeout(r, 0));
}
}为什么 requestIdleCallback 不适合替代 yield
requestIdleCallback() 常被建议用于“空闲时执行”，但它不能主动让出当前执行权，只负责在将来空闲时段调度回调。如果你正在一个同步长任务里，它不会中断你，也不会提升当前输入响应性。
立即学习“前端免费学习笔记（深入）”；
- 它不解决“当前阻塞”问题，只解决“后续安排”问题
- 触发时机不可控（可能几秒后才执行），且在页面后台或低优先级标签页中可能被跳过
- 无法保证输入事件一定在下一次 callback 前被处理
容易踩的坑：yield 的幻觉与真实代价
即使你模拟出类似 yield 的行为，也要清醒认识它的成本和边界：
- 每次
setTimeout(..., 0)至少引入 ~4ms 延迟（浏览器最小定时器精度），高频调用会显著拖慢总耗时 - 频繁打断会破坏 CPU 缓存局部性，对计算密集型任务反而降低吞吐
- 不能在事件处理器内无脑插入 —— 比如
input事件中每打一个字都 yield，会放大响应延迟感 - Web Worker 才是真正的解耦方案；主线程 yield 只是“止痛剂”，不是“根治”
真正需要响应性时，优先考虑把计算移到 Worker，而不是靠 yield 折腾主线程。
