1、引言：为什么需要运行时初始化？从main函数之前的世界讲起。
说实话，我刚开始学嵌入式那会儿，也以为程序就是从 main() 开始的。
老师教我们写 int main(void)，然后点亮一个LED，跑个串口打印。一切看起来顺理成章。直到有一次，我在一个项目里遇到了一个极其诡异的问题——芯片上电后，程序死活跑不起来，但同样的代码在开发板上就没事。
我折腾了整整两天，最后发现，问题出在 main() 之前。
嗯，你没听错。在 main() 函数的第一行代码被执行之前，芯片已经干了很多事。这些事，就是所谓的「运行时初始化」。如果你不懂它，你写的代码就像盖在沙滩上的城堡——看着漂亮，一碰就塌。
1.1 一个被忽略的真相：main() 不是起点
我们来看一个最简单的例子。你写了个C程序：
int global_var = 0x55;
static int static_var = 0xAA;
int main(void) {
volatile int local_var = 0x01;
while(1);
return 0;
}
你觉得 global_var 和 static_var 的值是什么时候写进内存的？
很多人会回答：「编译的时候就确定了。」
对了一半。编译确实确定了它们的初始值，但芯片上电那一刻，RAM里的数据是随机的。你想想看，如果没人把 0x55 和 0xAA 从Flash拷贝到RAM里，那 global_var 的值就是个垃圾。
这个拷贝动作，就是运行时初始化的一部分。它发生在 main() 之前。
核心观点： C程序的入口点是 _start 或 Reset_Handler，而不是 main()。main() 只是开发者看到的起点，在它背后，启动代码已经完成了一系列关键操作。
1.2 启动代码到底干了什么？
我个人习惯把启动代码的工作分成三个阶段。你可以把它想象成一场演出前的准备工作：
- 硬件初始化——给舞台通电、调灯光、摆好乐器。
- 数据段搬运——把乐谱从后台搬到谱架上。
- BSS段清零——把舞台上的杂物清空，确保每个位置都是干净的。
下面这张图，是我画的一个典型嵌入式系统的启动流程。你看一眼就能明白：
你看，从复位到 main()，中间隔了整整四步。每一步出了问题，你的程序都跑不起来。
1.3 为什么这些事不能交给编译器？
你可能会问：「这些初始化工作，为什么不能由编译器自动搞定？」
好问题。编译器确实能生成初始化代码——前提是你用的是标准C运行时环境。但在嵌入式世界里，情况要复杂得多。
我举个例子。我在一个项目中用过某款国产MCU，它的RAM分为两个区域：一段是掉电保持的，一段是普通的。如果启动代码不分青红皂白地把所有 .data 段都搬运过去，那掉电保持区域的数据就被覆盖了。你说这锅该谁背？
编译器不知道你的硬件布局。它只知道「把 .data 从Flash拷到RAM」，但它不知道你的RAM分了几块、哪块需要保持、哪块可以随便写。
所以，启动代码必须由你——或者芯片厂商——来写。它必须知道硬件的每一个细节。
我的建议： 不要直接复制粘贴芯片厂商提供的启动代码。至少读一遍，理解每一行在干什么。我曾经见过一个团队，因为用了错误的链接脚本，导致启动代码把数据写到了错误的地址，整批产品都出了问题。
1.4 一个典型的启动代码片段
下面是一个简化的启动代码（汇编），它展示了从复位到 main() 的核心逻辑。我把它拆成了几个关键步骤：
; 简化版启动代码（ARM Cortex-M 风格）
Reset_Handler:
; 1. 设置主堆栈指针
LDR R0, =_estack
MSR MSP, R0
; 2. 搬运 .data 段
LDR R0, =_sdata ; RAM 起始地址
LDR R1, =_edata ; RAM 结束地址
LDR R2, =_sidata ; Flash 中的源地址
BL data_copy
; 3. 清零 .bss 段
LDR R0, =_sbss
LDR R1, =_ebss
BL bss_clear
; 4. 调用 C 库初始化（可选）
BL __libc_init_array
; 5. 跳转到 main
BL main
; 如果 main 返回，则死循环
B .
这段代码看起来简单，但每一行背后都有讲究。比如 _estack 这个符号，它来自链接脚本。如果链接脚本里写错了堆栈地址，那程序一启动就崩了。
注意： 很多初学者在移植代码时，只改了 main() 里的逻辑，却忘了检查链接脚本和启动代码。结果就是——程序在开发板上跑得好好的，换到自己的板子上就黑屏。我踩过这个坑，真的。
1.5 运行时初始化的「隐形」工作
除了搬运数据和清零，运行时初始化还干了一些你可能没注意到的事：
| 初始化项 | 说明 | 如果不做会怎样？ |
|---|---|---|
| 堆栈指针设置 | 告诉CPU栈顶在哪里 | 函数调用、中断一进来就崩 |
| 中断向量表重定位 | 把中断向量表放到正确位置 | 中断来了找不到处理函数 |
| 全局/静态变量初始化 | 把初始值从Flash拷到RAM | 全局变量值是随机的，逻辑全乱 |
| BSS段清零 | 把未初始化的全局变量设为0 | 变量初始值不确定，行为不可预测 |
| C库初始化 | 初始化堆、标准I/O等 | malloc、printf等函数无法使用 |
| 构造函数调用 | 调用C++全局对象的构造函数 | 全局对象无法正确初始化 |
你看，这些工作每一个都至关重要。而且它们有一个共同点：必须在 main() 之前完成。因为 main() 的第一行代码，可能就要用到全局变量，或者调用 printf()。
1.6 为什么你现在必须搞懂它？
说实话，如果你只是写写应用层代码，可能一辈子都用不到这些知识。但如果你想深入嵌入式底层，想自己写Bootloader、做RTOS移植、或者调试一些莫名其妙的启动问题——那你就绕不开它。
我记得有一次，一个同事问我：「为什么我的程序在仿真器里能跑，脱机就不行？」
我让他检查启动代码里的堆栈设置。结果发现，他的链接脚本里堆栈地址写错了，仿真器启动时自动修正了这个问题，但脱机运行时没人帮它修正。
这就是典型的「main之前的世界」出的问题。你如果不懂，就只能靠猜。你如果懂了，一眼就能看出问题在哪。
一句话总结： 运行时初始化是C程序从「死代码」变成「活程序」的关键一步。它负责把编译好的二进制文件，变成能在硬件上正确运行的状态。没有它，你的 main() 就是个空壳。
好了，这一章我们聊了为什么需要运行时初始化，以及它在整个启动流程中的位置。下一章，我会带你深入启动代码的细节，看看那些汇编指令到底在干什么。
公众号:蓝海资料掘金营，微信deep3321