回调函数原理：定义、使用场景与基本实现
什么是回调函数？
先不看教科书上的定义。我换个说法——回调函数就是一个“你说一声，我来处理”的约定。你把自己的一段逻辑交给另一个函数，让它做完事后通知你。就这么简单。
举个例子。你点了一份外卖，留下手机号。外卖小哥送到后打电话给你。那你的手机号就是“回调函数”，外卖系统就是“异步任务”。电话接通那一刻，就叫“回调被触发”。
从代码角度看，回调就是一个作为参数传入的函数。调用方不立即执行它，而是在某个条件满足后才调用它。
def on_data_received(data):
print(f"收到了数据：{data}")
def fetch_data(callback):
# 模拟异步网络请求
import time, threading
def worker():
time.sleep(1)
callback("Hello from server")
threading.Thread(target=worker).start()
fetch_data(on_data_received)
# 此处不会阻塞，1秒后打印
这段代码里，on_data_received 就是回调函数。它被传给 fetch_data，等数据准备好了再被调用。说白了，这是一种“反向控制”——调用者把控制权暂时交给被调用方，后续由被调用方决定什么时候执行你的逻辑。
回调的使用场景
说到场景，我先说说我在项目中碰到的几类典型情况。
- 异步 I/O 操作：读写文件、网络请求、数据库查询。主线程不能卡死，就用回调来通知完成。
- 事件驱动编程：按钮点击、键盘输入、系统信号。GUI 框架里到处是回调。
- 中间件扩展：SDK 允许用户插入自定义逻辑。比如支付成功后执行你的回调。
- 任务编排：一个任务完成后自动启动下一个任务，串行或并行。
嗯，这些场景都有一个共性：调用者不知道什么时候结束，也不知道结果怎么处理。回调就充当了一个“插槽”，让调用者把处理逻辑放进去。
基本实现模式
实现回调通常有两种模式：函数指针（或函数对象）和接口/委托。Python 里直接用函数对象就行，C 语言用函数指针，Java 则常用匿名内部类或 Lambda。
| 语言 | 实现方式 | 典型代码片段 |
|---|---|---|
| Python | 函数作为参数 | def on_done(): pass; do_task(on_done) |
| JavaScript | 箭头函数 / function 表达式 | doTask(() => alert('done')) |
| Java | 接口 + Lambda | doTask(() -> System.out.println("done")) |
| C# | 委托 / Action / Func | doTask(() => Console.WriteLine("done")) |
| C++ | std::function / Lambda | doTask([](){ std::cout << "done"; }) |
你看，核心思想都一样。我个人习惯在 SDK 设计里统一用 回调签名的文档约定，比如参数类型、返回类型、是否允许异常抛出。这能避免很多运行时错误。
回调执行的两种时机
回调触发的时间点有两种：同步回调和异步回调。二者本质区别在于：回调是在当前堆栈里执行，还是在新堆栈里执行。
同步回调：调用者把回调传进去，被调用者在返回之前直接调用回调。整个过程是阻塞的，回调与主逻辑在同一个线程。
异步回调：被调用者启动一个异步操作后立即返回，等操作完成后（可能在新线程或事件循环里）再调用回调。主线程不会被阻塞。
举个生活中例子。你打电话问客服“余额多少”，客服当场查完告诉你——这就是同步回调。如果你发短信查余额，客服收到短信后查完再打电话给你——这就是异步回调。
小提示：异步回调一定要考虑线程安全。我曾经在写 SDK 时，回调里直接更新 UI 控件，结果频繁 Crash。后来才意识到回调跑在 Worker 线程，而 UI 只能在主线程更新。加一个 invokeOnMainThread 就解决了。
常见陷阱与避坑
回调用得不好，容易踩坑。我总结了几个高频问题。
1. 回调地狱
嵌套太多回调，代码变成“倒三角形”。可读性极差。解决方案：用 async/await 或 Promise 链式调用。但这不是本章重点，后面我会专门讲。
2. 忘记调用回调
分支逻辑里少写了回调调用，导致永远等不到结果。我建议：在函数出口统一调用回调，或者用 try/finally 保证必执行。
def fetch_user(user_id, on_success, on_error):
try:
user = db.query(user_id)
if user is None:
on_error("User not found")
return
on_success(user)
except Exception as e:
on_error(str(e))
3. 回调调用次数不唯一
一个回调可能被调用多次，比如网络重试场景下。我曾经接手过一个老 SDK，里面的回调被调用两次，导致业务重复扣款。后来加了一个 called 标记才修复。
注意：设计回调契约时，一定要明确“保证单次调用”还是“允许多次调用”。通常推荐 一次且只有一次（exactly-once）。
回调执行流程 SVG 图
下面这张图把整个回调执行链路梳理清楚了。左侧是主模块，中间是异步任务，右侧是回调函数。箭头表示数据流和控制流。
我的个人建议
回调在 SDK 集成里太常见了。我做了多年 SDK 开发，最大的体会是：回调签名设计要尽量简单。能传两个参数就别传五个。能抛异常就别吞掉。还有，一定要清楚你的回调是在什么线程执行的，不然调试起来会很痛苦。
另外，我建议在回调中使用卫语句（guard clause）处理空值。比如检查回调是否为 None，不然运行时可能会因 NoneType 不可调用而崩溃。
def perform_action(callback=None):
# 模拟耗时操作
result = do_some_work()
if callback is not None:
callback(result) # 安全调用
嗯，这一节就聊到这里。回调函数这个基础概念看起来简单，但实际工程中要注意的细节不少。掌握好它，后面学习 Promise、async/await 就会轻松很多。