如果要理解回调，需要在分同步通信、异步通信的基础上了解
举个通俗的例子：
你打电话问书店老板有没有《JS》这本书，如果是同步通信机制，书店老板会说，你稍等，”我查一下"，然后开始查啊查，等查好了（可能是5秒，也可能是一天）告诉你结果（返回结果）。而异步通信机制，书店老板直接告诉你我查一下啊，查好了打电话给你，然后直接挂电话了（不返回结果）。然后查好了，他会主动打电话给你。在这里老板通过“回电”这种方式来回调。
同步是阻塞模式，异步是非阻塞模式，在程序设计中，特别是用户交互功能上采用非阻塞模式的异步可以有效的提高用户的使用满意度，比如我们在手机端提交一个订单，点击提交后，首先是看到按钮被禁用，稍后提示成功下单。
同样是这个下单的例子，如果让下面的模式设计可能效果就不一样了：
- 整个过程采用同步方式，点击提交按钮，程序开始同步访问网络，阻塞模式被启用，程序当前类似死机卡着不动，但看上去还好像正常，只是对任何用户操作都无法响应。大约4、5秒以后提示成功或失败。
- 整个过程仅仅采用异步模式，用户点击提交按钮后程序返回已提交，程序开始后台处理网络请求。
第一种情况肯定是糟糕的用户体验，用户交互被短时间的暂停，用户点击按钮后没有任何反馈，也无法预测接下来是什么状况，给人一种出了问题的印象。
第二种情况也好不到哪里去，用户是立马获得了反馈，但是这种反馈过于突然，尽管如此，用户下意识觉得应该没问题。但一旦经过一段时间的使用才发觉实际上当初的操作结果其实不是预期的，糟糕的用户体验也莫过如此了。其实这个过程就是因为缺少了及时 “回调”。