回调机制基础：理解你的代码如何“留号码”

聊到回调，很多人第一反应就是“函数里传函数”。这话没错，但太糙了。

我做SDK这些年，发现大部分回调相关的bug，根源都不是写法问题，而是开发者没搞懂回调的本质是什么。它说白了就是个“留号码”的机制——你给系统或底层库留个电话号码（回调函数），等事情办完了，它打给你。

嗯，这一章我们就把这个号码本彻底拆开看。

回调函数：到底什么是“回调”？

先看一个最朴素的例子。你家里水管漏水，你给物业打电话。物业说“我记下了，修好了通知你”。你挂了电话，继续干你的事。修好了，物业打电话告诉你“行了，回家吧”。

在这个场景里，你留给物业的那句“修好了通知我”，就是回调函数。代码长什么样？大概是这样：

void repair_done(void *context) {
    printf("水管修好了，可以回家了！\n");
}

// 物业的维修函数
void call_plumber(callback_t on_done, void *ctx) {
    // 安排师傅去修...
    // 修好了，调用回调
    on_done(ctx);
}

int main() {
    call_plumber(repair_done, NULL);
    return 0;
}

看到没？repair_done这个函数，不是在main里直接调用的，而是被当作参数传给了call_plumber，由它来决定什么时候调用。这就是回调的核心——控制权反转。

事件驱动模型：别主动问，等着被通知

你想想看，传统编程是什么模式？顺序执行：你写一行，电脑跑一行，跑完你再写下一条。但在网络通信、SDK初始化这些场景里，这种模式行不通。为什么？因为你不知道加密握手什么时候完成，不知道对端什么时候发数据过来。

这时候就要事件驱动登场了。

事件驱动的核心思想就四个字：注册-通知。你提前把你的兴趣（事件）和你的处理逻辑（回调函数）注册到事件循环里。系统检测到事件发生，就去查注册表，找到对应的回调并调用它。这个过程里，你的主线程不需要轮询，不需要sleep等待，CPU利用率极高。

事件驱动模型在现代SDK里几乎是标配。比如在加密握手场景中，你需要监听“握手成功”事件和“握手失败”事件，每个事件挂一个回调。系统处理完SSL/TLS握手，就会触发对应的回调。你不用在代码里写while循环去猜：“握手完了没？完了没？完了没？”

同步回调与异步回调：一个打直球，一个绕弯子

很多人搞混这两个概念。我刚开始接触异步编程时，也栽过跟头。现在用一个你一定能分清楚的对比来讲。

对比维度	同步回调	异步回调
调用时机	在函数返回之前立即执行	在函数返回之后的某个时刻执行
阻塞情况	会阻塞调用线程	不会阻塞调用线程
代码流程	线性、可预测	非线性、事件驱动
典型场景	qsort的比较函数、for_each	网络IO、文件读写、加密握手
上下文	在调用者的上下文中执行	通常在独立线程或事件循环中执行

同步回调：就像你去餐厅点餐，站在柜台前等。厨师做好一份，递给你，你接过来吃了，然后才能点下一份。流程是串行的，每一步都等着上一步完成。这种回调实现简单，但效率低——发个网络请求要是用同步回调，整个线程就卡在那了。

异步回调：你点完餐，拿个号，找个位子坐着刷手机。厨师做好，叫号，你去取餐。这个过程里你没有阻塞，想干嘛干嘛。异步回调的核心就是一个“延迟执行”——你告诉系统：“我把这个函数交给你，等你把事办完了，找个合适的时间帮我跑一下。”

为什么加密握手必须用异步回调？

我们来分析加密握手的生命周期。一次典型的TLS握手，涉及证书验证、密钥协商、算法套件确认等多个步骤，其中还可能包含网络往返。这个过程的耗时，少则几十毫秒，多则几秒甚至更长。如果用同步回调，等握手完成再干别的事，你的应用响应性就废了。

异步回调正好解决这个痛点：

1. 发起握手：调用SDK的startHandshake()，传入回调函数。
2. 立即返回：startHandshake函数立刻返回，主线程继续做其他事。
3. 后台执行：握手过程在另一个线程或事件循环中运行。
4. 回调触发：握手完成或失败，SDK调用你注册的回调函数。

整个过程，你的主线程一秒都没浪费。

本章知识体系总览

下面这张SVG图，把回调机制的核心脉络串起来了。建议你边看边思考：你的SDK里，哪些地方用了同步回调？哪些应该改成异步的？

从这张图你可以看到，整个回调机制的终点，就是我们课程的实战目标：加密握手的SDK初始化改造。事件驱动模型负责组织事件和回调的映射关系，异步回调保证不阻塞主线程，两者合力，才能构建出一个健壮的SDK初始化流程。