MessageChannel通过port1.postMessage()触发宏任务，使port2.onmessage在下一帧执行调度循环；其核心是每次只执行≤5ms任务并主动让出主线程，配合多级优先级队列实现插队与中断恢复。
MessageChannel 是怎么触发一次调度循环的
它不靠 setTimeout 或 Promise，而是用 port1.postMessage() 往宏任务队列里塞一个空消息，让 port2.onmessage 在下一帧被调用——这是 React 内部真正用的方式，比 setTimeout 更快、更稳定，且不会被浏览器节流。
常见错误是直接在主线程里循环执行任务，结果页面卡死；或者误用 Promise.then，导致微任务堆积、阻塞渲染。React 明确不用微任务，就是因为「必须让出主线程给 paint」。
关键点：
-
port2.onmessage是宏任务入口，每次只执行一次回调 - 回调内部要手动控制执行时长（比如 5ms），超时就主动退出，再发一次
postMessage - 不能把整个大任务塞进去执行，必须拆成可中断的小单元（即 Fiber 节点级 work）
如何实现 shouldYield 判断逻辑
shouldYield 不是魔法函数，它本质就是两个条件的组合判断：是否超时 + 是否有更高优先级待处理事件。
你不需要等浏览器原生支持 isInputPending()（目前仅 Chromium 87+），可以用降级方案模拟：
- 用
performance.now() - startTime >= 5做基础时间切片（React 默认 5ms） - 监听
document.addEventListener('keydown', ..., {passive: true})或用input事件标记「有用户输入待响应」 - 如果检测到输入事件，立刻返回
true，中断当前 work loop
注意：不要在 shouldYield 里做 DOM 查询或复杂计算，否则它自己就成了瓶颈。
任务队列怎么支持优先级插队
React 的 Lane 模型背后，其实是多级队列结构。你可以用数组索引代表优先级（数值越小越高），比如：
const taskQueues = [ [], // IMMEDIATE [], // USER_BLOCKING [], // NORMAL [], // LOW [] // IDLE ];
每次调度时从索引 0 开始遍历，只要某一级非空，就先消费它；高优先级任务 push 进来后，下一轮调度自然会先执行它。
容易踩的坑：
- 没清空高优队列就跳去执行低优任务 → 导致插队失效
- 把不同优先级任务混进同一个数组 → 完全失去调度意义
- 在
addTask里没做类型校验，传入非函数导致后续task()报错中断整个调度
为什么不能直接复用 React 的 Scheduler 包
React 的 scheduler 包是高度耦合 Fiber 架构的，暴露的 scheduleCallback 接口只接受 priorityLevel 和回调，不开放底层队列、shouldYield 实现或切片参数控制。
如果你只是想在非 React 环境（比如 Vue、纯 JS 工具库、AI 流式输出）里复现类似行为，手写一个轻量版更可控：
- 可以改
sliceTime（比如 AI 打字设为 10ms，动画设为 3ms） - 可以替换
isInputPending为自定义事件监听 - 可以加
cancelTask支持中止某类低优任务（如日志上报）
真正难的不是调度器本身，而是把业务逻辑正确地「切片」成可中断单元——这一步没人能替你做。
