普通 C 函数调用、主动任务切换与被动任务切换的3种情况的压栈内容对比

在操作系统和微处理器教科书里，通常只有后两者(主动任务切换和被动任务切换)被称为标准的 Context Switch。我们可以从计算机科学的定义边界来区分：

1. 为什么“普通 C 函数调用”通常【不被称为】Context Switch？在操作系统（OS）的语境下，Context Switch 特指“线程/任务/进程级别”的上下文切换。宇宙未变：普通函数调用发生时，CPU 依然在同一个任务的控制边界（TCB）和同一个栈空间里活动。没有剥夺所有权：它没有改变当前 CPU 正在服务的业务对象。对于操作系统内核而言，它甚至根本不知道、也不关心你在任务内部调用了多少个子函数。因此，在专业语境下，函数调用通常被称为 Procedure Call（过程调用） 或 Function Call，其压栈过程称为 Stack Framing（建立栈帧）。

2. 为什么“主动”和“被动”任务切换是【真正的】Context Switch？因为它们满足了上下文切换的硬性物理定义：彻底冻结与复活：物理 CPU 核心内的全套寄存器（整个世界的运行状态），从属于“任务 A 宇宙”彻底打包剥离，换成了“任务 B 宇宙”的全套数据。控制权转移：操作系统的调度器参与了控制，更新了 pxCurrentTCB，改变了 SP 指针的物理指向。

3. 广义上的统一：它们本质上都在做“现场保护”如果跳出操作系统的框架，站在 CPU 硬件核心（Core） 的冷酷视角来看，这三种情况在底层逻辑上确实是同一种哲学的延伸：无论是函数调用（防寄存器冲突）、主动切换（防任务丢失）还是中断抢占（防突发打断），它们的核心动作全都是：“由于物理寄存器数量有限，为了去干另一件事，必须把当前寄存器里的旧物资（Context）挪到物理 RAM 栈里腾出地方，办完事后再挪回来。所以，在理解上完全可以将它们归为广义的Context Switch，但严格来说：只有任务（Task/Thread）之间的切换才叫 Context Switch，而函数调用只是普通的栈帧变化。