回调函数：先走一步，好了叫我
同步 vs 异步：再回到餐厅
还记得那家餐厅吗？让我们更具体一点：
同步模式就像自己做饭——你得亲自站在锅前，炒完一个菜才能做下一个。做三个菜要依次等每一个做完。
异步模式就像在餐厅点菜——你把三道菜的点单交给服务员，然后你就可以刷手机、和朋友聊天了。菜做好了，服务员自然会端上来。
用代码来理解——先看同步的世界：
看起来没什么问题？那是因为这些操作都是"瞬间完成"的。一旦有了"慢操作"，就不一样了。
什么是回调函数？
回调函数（callback） 的思想很简单：你把一个函数交给别人，说"等你做完了，回来调用这个函数告诉我"。
就像你在奶茶店点单，留了个手机号——奶茶做好了，店员回拨你电话。这个"回拨"就是回调。
JS 中的异步回调
在 JS 里，回调最重要的用途是处理异步操作。最经典的例子是 setTimeout——设定一个计时器，时间到了再执行回调：
注意输出的顺序！JS 的 setTimeout 不会阻塞程序——它只是"预约"了一个回调。程序继续往下跑，到时间了再执行回调。
这是 JS 异步编程最核心的特点：不等待，先走为敬。
试着问 AI："为什么 setTimeout 回调里的代码比后面的 console.log 更晚执行？JS 的事件循环是怎么安排这些任务的？"
回调的实际应用
在真实的 JS 开发中，回调常用于事件监听和异步 I/O。让我们看一个模拟网络请求的例子：
看到了吗？Python 直接 return 结果就好了，而 JS 要把"成功了怎么办"和"失败了怎么办"都作为函数传进去。这种模式在早期的 JS（Node.js）中非常普遍。
回调地狱 (Callback Hell)
问题来了——如果你要做一连串异步操作呢？比如：先查用户，再查订单，再查商品详情……
看到 JS 那边的代码了吗？每一层异步操作就要嵌套一层回调，代码向右无限缩进，形成了一个"金字塔"——这就是臭名昭著的回调地狱（Callback Hell），也叫"末日金字塔"（Pyramid of Doom）。
如果再加上错误处理，情况会更糟糕：
getUser(1, (user) => {
if (!user) { handleError("用户不存在"); return }
getOrder(user.orderId, (order) => {
if (!order) { handleError("订单不存在"); return }
getProduct(order.productId, (product) => {
if (!product) { handleError("商品不存在"); return }
// 终于可以处理正常逻辑了……
})
})
})
每一层都要检查错误，每一层都要缩进，代码变得又深又难读。
问问 AI："为什么 JavaScript 是单线程的？如果它像 Python 一样可以用多线程，还需要回调吗？"
这个问题会带你了解 JS 的设计哲学——它的单线程模型是刻意选择的，而不是技术限制。
从回调到 Promise
正是因为回调地狱的存在，JS 社区在 2015 年（ES6）引入了 Promise——一种更优雅的异步处理方式。
打个比方：
- 回调就像你告诉服务员："菜好了你喊我一声。" 但如果你要点好几道菜，每道菜都要交代一遍怎么通知你，搞得乱七八糟。
- Promise就像服务员给你一个取餐号。你拿着号码牌，想什么时候去取就什么时候去取。你还可以把多个号码牌串起来管理——"先等主菜，然后上甜品"。
那么 Promise 到底长什么样？我们下一节见！
小结
| 概念 | Python | JavaScript |
|---|---|---|
| 同步执行 | 默认方式 | 也支持 |
| 异步回调 | 不常用 | 核心模式 |
setTimeout | 无直接等效 | setTimeout(fn, ms) |
| 回调地狱 | 不存在 | 层层嵌套，代码难读 |
| 解决方案 | asyncio（后话） | Promise（下一节） |
一句话：回调是异步编程的起点，但不是终点。 回调地狱让无数 JS 开发者痛苦不堪，于是 Promise 应运而生。