Task Source是规范中用于区分宏任务来源的抽象概念，决定回调进入哪个宏任务队列，保证同源FIFO但不规定跨源优先级，仅作用于宏任务层面，与微任务无关。
Task Source（任务源）是规范中用于区分不同异步操作来源的抽象概念，它本身不直接暴露给开发者，但深刻影响着浏览器如何将回调分发到对应的宏任务队列，并间接参与调度优先级的判定。
任务源决定回调进入哪个宏任务队列
规范要求每个宏任务必须关联一个明确的任务源，比如：
-
timer task source：对应
setTimeout、setInterval - user interaction task source：对应点击、键盘等 DOM 事件
-
network task source：对应
fetch、XMLHttpRequest完成回调 - history traversal task source：对应前进/后退导航完成
- canvas blob task source：用于 Canvas 相关异步操作
同一任务源产生的宏任务，会按插入顺序排队；但不同任务源之间，**浏览器没有强制规定全局优先级顺序**。也就是说，规范只保证“同源 FIFO”，不保证“跨源谁先谁后”。实际执行顺序取决于浏览器实现和当前上下文（如用户是否正在交互）。
浏览器可基于任务源动态调整调度策略
虽然规范未定义跨源优先级，但现代浏览器普遍采用启发式策略提升响应性：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 用户交互任务源（如 click）通常被赋予更高调度权重，避免输入延迟
- 网络任务源在页面加载初期可能被适度延后，防止抢占渲染资源
- 定时器任务源在空闲时段可能被合并或节流（尤其
setTimeout(fn, 0)）
这种调度不是靠改变队列结构，而是通过内部调度器对不同任务源的出队时机施加影响——例如，即使 timer 队列里有个任务已就绪，若此时用户刚按下按钮，浏览器可能先取出 interaction 队列里的任务执行。
任务源与微任务无直接关系
微任务队列（Promise.then、MutationObserver、queueMicrotask）不按任务源划分。所有微任务统一进入同一个先进先出队列，且在每次宏任务结束后**立即全部清空**。任务源概念仅作用于宏任务层面，不影响微任务的插入或执行逻辑。
开发中不需要手动指定或识别任务源
JavaScript 没有 API 让你读取或设置某个回调的任务源。它的存在主要是为了规范多线程协作（Web APIs 线程向 JS 主线程投递任务时需标注来源），并为浏览器实现留出优化空间。你只需记住：相同类型的操作（如两个 setTimeout）必然同源，而不同类型的操作（如 setTimeout 和 click）谁先执行，不能绝对预测——但微任务永远插在它们中间执行。
