JavaScript是同步执行的，为什么需要使用callback回调函数？

首先纠正一个认知偏差 #

JavaScript 引擎本身是单线程同步执行的，但它的宿主环境（浏览器、Node.js）提供了多线程的异步处理能力，回调函数就是用来衔接同步执行逻辑和异步任务结果的核心方案之一。

两段功能一致代码的核心差异 #

你看到的只是当前场景下静态功能一致，二者的扩展性和耦合度完全不同：

• 硬编码写法：函数a内部写死了执行完自身逻辑后必须调用b，如果后续需求变化，要让a执行完后调用c、d或者其他自定义逻辑，必须修改a的内部代码，逻辑完全耦合，复用性极低。
• 回调写法：函数a和后续执行逻辑完全解耦，a只需要约定「执行完自身逻辑后，会调用传入的回调函数」，你想让a执行完做什么，就把对应的函数当参数传进去即可，不需要改动a的任何内部代码，复用性和灵活性极高。

举个简单的例子：用回调写法时，你可以直接执行a(() => console.log("自定义的新逻辑"))就能实现任意后续需求，硬编码的写法完全做不到这一点。

回调函数的实际应用场景 #

1. 异步逻辑处理

这是回调最常见的使用场景：JS 主线程不会等待异步任务（定时器倒计时、网络请求、用户交互事件）的结果，会把异步任务交给宿主的其他线程处理，同时约定好异步任务完成后要执行的回调函数。等异步任务完成后，宿主会把回调函数塞到JS主线程的执行队列里，等主线程空闲后就执行回调，既不会阻塞主线程的同步代码执行，也能在异步任务完成后执行对应的处理逻辑。
常见例子：

• DOM 事件监听：button.addEventListener('click', () => { /* 点击后的处理逻辑 */ })，第二个参数就是回调
• 定时器：setTimeout(() => { /* 倒计时结束后的逻辑 */ }, 1000)
• 早期的网络请求API：XMLHttpRequest的onload回调

2. 同步逻辑的复用扩展

很多通用的工具函数只需要封装固定流程，流程中可变的逻辑可以通过回调交给调用方自定义，不需要修改工具函数本身的代码，符合开闭原则。
常见例子：

• 数组遍历方法：[1,2,3].map(item => item * 2)，传入map的函数就是回调，map只负责遍历数组，每个元素的处理逻辑完全由调用方自定义
• 通用表单校验函数：校验逻辑是固定的，校验通过后的提交、跳转等逻辑是可变的，就可以把后续逻辑作为回调传入，不同业务场景传不同的回调即可。

内容的提问来源于stack exchange，提问作者syed irfan