javascript单线程下，同步任务阻塞主线程和事件循环，导致异步回调延迟执行；异步任务的回调被放入任务队列或微任务队列，须等调用栈清空后才由事件循环调度执行。
同步任务本身不会“阻塞异步触发”，但**它会阻塞事件循环或主线程，从而延迟异步任务的执行时机**——这不是异步逻辑被禁止了，而是其回调/任务被推迟调度。
同步代码如何影响异步任务执行
在单线程环境（如 JavaScript 的浏览器主线程、Node.js 的 event loop 主线程）中：
- 所有同步代码会按顺序压入调用栈，逐行执行，直到栈清空；
- 异步操作（如
setTimeout、Promise.then、fetch回调）的回调函数，不是立刻执行，而是被放入**任务队列（task queue）或微任务队列（microtask queue）**； - 这些队列中的回调，只有在**当前调用栈完全为空、且上一轮事件循环结束之后**，才会被取出执行；
- 因此，一段耗时的同步代码（比如
while(Date.now() 或大量计算），会让调用栈长时间不空，导致异步回调“卡住”，看似被“阻塞”。
典型例子：同步忙等锁死异步回调
以下代码中，setTimeout 注册了 0ms 延迟，但它的回调要等 2 秒同步循环结束后才执行：
console.log('start');
setTimeout(() => console.log('timeout'), 0);
let start = Date.now();
while (Date.now() - start <p>输出顺序是：<code>start → end → timeout</code>。
<code>timeout</code> 并没被取消或禁止，只是它的回调一直躺在宏任务队列里，等不到执行机会。</p><h3>根本原因：事件循环机制限制</h3><p>关键不在“同步 vs 异步”的语义冲突，而在于运行时的调度规则：</p>
- 调用栈优先级最高：只要栈里有同步任务，事件循环就不会检查任何队列；
- 异步不是“并行执行”，而是“延迟调度”：它依赖空闲的调用栈来启动回调；
- 没有真正的抢占式调度：JavaScript 没有线程中断机制，同步代码一旦开始，必须跑完；
- 即使使用
Web Worker或child_process做 CPU 密集型任务，若仍在主线程做同步计算，依然会卡住 UI 和异步响应。
怎么避免？关键做法
不是消灭同步，而是不让它垄断主线程：
- 把长耗时计算拆成小块，用
setTimeout/queueMicrotask让出控制权； - 对密集型任务，移出主线程（如用 Web Worker 处理数据，再 postMessage 通知）；
- 避免
while(true)、大数组遍历不设限、正则回溯爆炸等隐式同步阻塞； - 注意
Promise构造器内的代码是同步执行的（new Promise(fn) 中的fn立即调用），别在里面写耗时逻辑。
本质上，这不是同步“故意阻塞”异步，而是单线程环境下资源独占带来的自然结果。理解调用栈与事件循环的协作关系，才能真正掌控执行节奏。
