同步与异步的性能边界在于调用栈是否因等待结果而停滞执行：满足无返回即挂起、栈帧无法出栈或无并发调度介入任一条件，即为调用栈阻塞；有回调不等于非阻塞，关键看控制权是否真正让出。
同步与异步的性能边界，不在于“快或慢”，而在于调用栈是否因等待结果而停滞执行。判定是否阻塞调用栈，关键看：当前线程在发起调用后，是否必须停在原地、无法推进后续代码——这才是真正影响响应性与吞吐量的临界点。
调用栈阻塞的三个硬性判定标准
满足任一条件，即视为调用栈被阻塞（同步+阻塞）：
-
无返回即挂起：函数调用发出后，控制权未交还给调用者，且当前线程无法执行任何后续语句（如 JS 中
fetch().then()不阻塞，但XMLHttpRequest.send()同步模式会）； -
栈帧无法出栈：调用函数的栈帧持续保留在调用栈顶部，直到底层 I/O 或计算完成（例如 Python 的
requests.get()默认行为）； - 无并发调度介入：系统未启用事件循环、线程池或协程调度器来接管耗时任务——换言之，没有“让出控制权”的机制支撑。
为什么“有回调”不等于“不阻塞调用栈”
常见误区：只要用了回调或 Promise 就算异步。实际上，若回调运行在同一线程且调用方仍需轮询、忙等待或主动 sleep 等待触发时机，调用栈依然被逻辑阻塞。
- 比如用
while !done: pass等待异步任务标记位——CPU 占满，栈未释放，仍是阻塞； - 再如 Java 中
Future.get()在未完成时直接阻塞当前线程，虽属异步发起，但调用栈在此刻被冻结； - 真正的非阻塞异步，要求调用后立即返回，且后续逻辑可由事件循环/调度器在适当时机自动恢复（如 Node.js 的
setTimeout、Go 的 goroutine yield）。
性能边界的实操识别方法
不用工具也能快速判断：把调用语句替换成一个“休眠 1 秒”的模拟操作，观察以下现象：
- 若替换后，整个函数或主线程暂停 1 秒才执行下一行 → 调用栈阻塞；
- 若替换后，下一行立刻执行，1 秒后才收到通知或结果 → 调用栈未阻塞；
- 若替换后，程序卡死或 UI 冻结（如浏览器页面无响应）→ 典型同步阻塞场景，尤其常见于主线程中未脱离开销操作。
边界不是技术栈决定的，而是控制流决定的
同一语言里，同步/异步、阻塞/非阻塞可自由组合。关键不在用什么 API，而在你如何组织控制流：
- Node.js 的
fs.readFileSync()是同步阻塞；fs.readFile()是异步非阻塞； - Python 的
time.sleep()阻塞主线程，但asyncio.sleep()不阻塞事件循环； - C++ 中
std::this_thread::sleep_for()阻塞当前线程，而std::async+future.wait_for()可实现非阻塞等待（取决于 wait 方式）。
