从main到硬件：STM32与PC的C程序启动差异及GPIO八种模式详解

1. 从一个最朴素的疑问说起

写了这么多年 C 语言，你有没有在某个深夜盯着屏幕想过一个问题：我在 PC 上敲下的那个int main()，和我在 STM32 工程里看到的那个int main()，明明长得一模一样，为什么一个跑在 Windows 上弹个黑框，另一个却能点亮一块开发板上的 LED？更让人困惑的是，STM32 的main函数里往往只有寥寥几行初始化代码，然后就是一个while(1)死循环，那些 GPIO 翻转、串口收发、定时器中断，到底是谁在背后调度？

这个问题看起来像是初学者才会问的，但我发现很多做了两三年嵌入式的朋友，其实也没有真正把这条链路捋清楚。大家习惯了在 Keil 或 STM32CubeIDE 里点一下“编译下载”，程序就跑起来了，至于从main到硬件引脚之间发生了什么，往往是一笔糊涂账。这篇文章就想把这条链路从头到尾拆开，讲清楚一个 C 程序的main在通用计算机上和在 STM32 上分别意味着什么，代码从main出发之后到底去了哪里，以及为什么 STM32 的main里必须有一个永不退出的循环。

先把结论摆在前面：PC 上的main是操作系统调用的一个普通函数，它返回了程序就结束；STM32 上的main是复位向量最终跳转到的入口，它一旦返回，整个系统就失去了落脚点，所以必须用while(1)把自己钉死。这个差异的根源，在于两者脚下站着的“地基”完全不同——一个是操作系统，一个是裸机硬件。

这篇文章适合谁看？如果你正在从 C 语言语法过渡到单片机开发，或者你已经在用标准外设库写 STM32 项目但对启动流程一知半解，又或者你只是单纯好奇“我的代码后来去了哪里”，那接下来的内容应该能帮你把脑子里那团模糊的东西理清楚。我会尽量少堆术语，多用类比，把启动文件、向量表、复位流程、GPIO 初始化这些环节串成一条完整的线。

2. 两种 main 的本质差异：地基不一样

2.1 PC 上的 main 是“被调用者”，STM32 上的 main 是“被跳转者”

在 PC 上写 C 程序，你编译出来的可执行文件并不是直接跑在 CPU 上的。中间隔着一层操作系统，还有一层 C 运行时库。当你双击一个 exe，操作系统的加载器会把程序读进内存，做好地址映射，然后调用 C 运行时库的启动代码，这个启动代码做完一系列准备工作之后，才会去调用你写的main。所以 PC 上的main本质上是一个被调用的函数，它执行完return 0，控制权就交还给运行时库，运行时库再通知操作系统，进程结束，资源回收。

STM32 这边完全是另一套逻辑。芯片上电或者按下复位键的那一刻，CPU 从固定的地址开始取指令，这个地址里放的不是你的main函数，而是一条跳转指令，指向启动文件里的一段汇编代码。这段汇编代码负责把该准备的都准备好，最后才跳转到main。注意我用的是“跳转”而不是“调用”，因为main在这里不是一个会被返回的函数，它是整个程序的终点站。你如果在 STM32 的main里写了return 0，编译器不会报错，但程序的行为就完全不可预测了——大概率是跑飞，因为没有任何代码等着接收这个返回值。

这个差异用一个类比来说：PC 上的main像是公司里的一个部门经理，他上面还有总经理（操作系统），他汇报完工作就可以下班；STM32 上的main像是被空投到荒岛上的探险队长，直升机（启动代码）把他放下来就飞走了，他必须自己搭帐篷、找水源，而且永远不能停下来，一停下来就完蛋。

2.2 为什么 STM32 的 main 里必须有一个死循环

很多人第一次写 STM32 程序时都会疑惑，为什么例程里main的最后永远是一个while(1)。这不是什么编程习惯问题，而是裸机环境的硬性要求。

在 PC 上，程序执行完main返回后，操作系统会接管，进程正常退出，内存释放，一切干干净净。但在 STM32 上，没有操作系统来接管。main返回后，CPU 会继续往下执行，而main后面的内存里放的是什么？可能是其他函数的代码，可能是未初始化的数据区，也可能是一片空白。CPU 不管这些，它会把里面的内容当作指令一条条执行下去，结果就是程序跑飞，行为完全不可控。

所以while(1)的作用不是“让程序一直运行”这么简单，它的本质是给 CPU 一个永远有指令可执行、但永远不会越界的地方。你可以把它理解成给程序挖了一个无限深的坑，CPU 掉进去之后就一直在里面转，不会跑到外面去闯祸。这个坑里具体做什么，才是你真正要实现的业务逻辑——读传感器、控制电机、刷新屏幕、响应按键。

注意：有些朋友会在while(1)里什么都不写，或者只写一个空语句。这在调试阶段可以接受，但在实际项目里，空循环会让 CPU 全速空转，功耗白白浪费。正确的做法是在循环里加入适当的延时或者进入低功耗模式，让 CPU 在没事做的时候歇一歇。

2.3 标准外设库在其中的角色

提到 STM32 开发，就绕不开标准外设库。虽然现在 ST 主推 HAL 库和 LL 库，但大量存量项目和教学材料仍然在使用标准外设库，尤其是那些基于 STM32F1 系列的经典教程。标准外设库做的事情，本质上就是把寄存器操作封装成函数，让你不用去查几百页的参考手册就能配置一个 GPIO。

比如你要点亮一个 LED，直接操作寄存器的话，你得知道 GPIO 端口的基地址、CRL 和 CRH 寄存器的位定义、时钟使能寄存器的位置，然后写一堆位运算。用标准外设库的话，你只需要调用GPIO_Init函数，传一个结构体进去，把模式、引脚、速度配好就行。库函数在背后帮你完成了那些繁琐的位操作。

但这里有一个容易被忽略的点：标准外设库的函数并不是什么魔法，它们最终操作的就是寄存器。你在main里调用的每一个库函数，编译之后都会变成对特定内存地址的读写指令。理解这一点很重要，因为它意味着当库函数出问题时，你完全可以绕过它直接操作寄存器来排查。我个人的习惯是，用库函数快速搭建原型，但在调试底层问题时，一定会打开参考手册对照寄存器来看。

3. 代码从 main 出发后的完整链路

3.1 上电复位到 main 之间的那段路

要讲清楚代码从main出发后去了哪里，得先讲清楚代码是怎么到达main的。这段路在 PC 上和 STM32 上完全不同，而恰恰是这段路，决定了main的行为方式。

STM32 上电后，CPU 首先从地址 0x00000000 处读取两个字。第一个字是初始栈顶指针的值，第二个字是复位向量的地址。复位向量指向的那段代码，就在启动文件里。启动文件通常是.s后缀的汇编文件，比如startup_stm32f10x_md.s这种。它做的事情按顺序大致是：设置栈指针、初始化时钟、设置中断向量表、调用SystemInit配置系统时钟、然后跳转到__main（注意这里是两个下划线，不是我们写的那个main）。

这个__main是编译器提供的 C 运行时入口，它负责初始化全局变量和静态变量，把已初始化的变量从 Flash 拷贝到 RAM，把未初始化的变量清零，然后才调用我们写的main函数。所以你在main里能直接用全局变量，是因为__main已经帮你把内存布局好了。

提示：如果你在调试时发现全局变量的初始值不对，或者未初始化的变量不是零，大概率是启动文件里的堆栈设置或者内存布局配置有问题。这种情况在更换芯片型号或者修改链接脚本之后特别容易出现。

3.2 main 里的初始化代码到底在做什么

理解了启动流程，再来看main里的代码就清晰多了。一个典型的 STM32 标准外设库工程的main函数，开头通常是一堆初始化调用，比如RCC_APB2PeriphClockCmd使能时钟、GPIO_Init配置引脚、USART_Init配置串口、NVIC_Init配置中断。这些初始化代码做的事情，本质上就是往特定的寄存器里写特定的值。

以 GPIO 初始化为例，标准外设库的GPIO_Init函数会根据你传入的结构体，计算出 CRL 或 CRH 寄存器应该写入的值，然后写进去。CRL 寄存器控制引脚 0 到 7，CRH 控制引脚 8 到 15，每个引脚占 4 个位，其中 2 位配置模式，2 位配置输出速度或输入模式。你选的 GPIO 模式不同，写进去的值就不同。

这里就引出了 GPIO 的 8 种工作模式这个话题。很多初学者在配置 GPIO 时都是照着例程抄，例程写什么模式就选什么模式，至于为什么选这个模式、换成别的模式会怎样，完全不清楚。实际上这 8 种模式的选择是有明确逻辑的，选错了轻则功能不正常，重则烧毁芯片。下一节我会专门展开讲。

3.3 while(1) 里的业务逻辑如何驱动硬件

初始化完成之后，程序进入while(1)循环，这里才是业务逻辑真正开始的地方。你在这个循环里读传感器、判断条件、控制输出，每一次循环都对应着一次硬件状态的更新。

但这里有一个关键问题：while(1)循环的执行速度非常快，STM32F103 在 72MHz 主频下，一个简单的循环可能几微秒就跑完一圈。如果你在循环里直接翻转 GPIO 来驱动 LED，LED 会以极高的频率闪烁，肉眼根本看不出来，看起来就像是常亮或者半亮。所以实际项目中，while(1)里通常会有延时函数、状态机判断、或者等待中断标志位的操作，让循环的节奏和实际需求匹配。

另一个常见的做法是把耗时的操作放到中断里处理，while(1)里只做状态调度。比如串口接收数据，你不需要在while(1)里不断查询接收标志位，而是配置串口接收中断，数据来了自动进中断处理，while(1)里只负责处理已经接收完整的命令。这样做的好处是 CPU 不用空转等待，效率更高，实时性也更好。

4. GPIO 八种工作模式的选择逻辑

4.1 八种模式的全景梳理

STM32 的 GPIO 有 8 种工作模式，这个数字让很多初学者头疼。但其实只要抓住两个维度就很好记：第一个维度是方向，输入还是输出；第二个维度是电气特性，是推挽还是开漏，是上拉、下拉还是浮空。

输入模式有四种：浮空输入、上拉输入、下拉输入、模拟输入。输出模式也有四种：推挽输出、开漏输出、推挽复用输出、开漏复用输出。这八种模式覆盖了几乎所有常见的外设连接场景，选型的时候只要问自己三个问题：这个引脚是往外输出信号还是从外面读信号？输出的时候需要强驱动还是只需要拉低？这个引脚是普通 GPIO 还是某个外设的复用功能？

下面这张表把八种模式的核心特征和典型用途列出来，方便对照：

4.2 输出模式：推挽和开漏到底怎么选

推挽输出和开漏输出是实际项目中最容易选错的一对。推挽输出的结构是上面一个 PMOS、下面一个 NMOS，输出高电平时 PMOS 导通，引脚被拉到 VCC；输出低电平时 NMOS 导通，引脚被拉到 GND。所以推挽输出既能强驱动高电平，也能强驱动低电平，驱动能力比较强。

开漏输出则只有下面的 NMOS，没有上面的 PMOS。输出低电平时 NMOS 导通，引脚拉到 GND；输出高电平时 NMOS 关断，引脚处于高阻态，电平由外部电路决定。所以开漏输出必须配合外部上拉电阻才能输出高电平，否则高电平就是悬空的。

那什么时候用开漏？最典型的场景是 I2C 总线。I2C 的 SDA 和 SCL 都是开漏结构，总线上挂多个设备，任何一个设备都可以把总线拉低，但没有任何设备能强行把总线拉高。这样多个设备就不会因为同时输出高电平而打架。另一个场景是电平转换，比如 3.3V 的 MCU 要和 5V 的器件通信，用开漏输出加上拉到 5V，就能安全地实现电平匹配。

推挽输出则适合大多数普通场景，比如驱动 LED、控制继电器、输出 PWM 波。但要注意，推挽输出不能把两个输出脚直接连在一起，否则一个输出高一个输出低，就会形成短路，时间长了可能烧毁引脚。

注意：有些开发板上的 LED 是接在 VCC 和引脚之间的，也就是低电平点亮。这种情况下用推挽输出没问题，但如果你不小心配成了开漏输出，低电平能点亮，高电平因为悬空可能微亮或者不亮，现象会很奇怪。遇到 LED 亮度不对，先检查输出模式。

4.3 输入模式：上拉、下拉和浮空的取舍

输入模式的选择相对简单一些，但也不是随便选。核心原则是：不能让引脚在空闲状态下悬空。悬空的引脚电平不确定，读进来的值可能是 0 也可能是 1，还可能因为环境干扰来回跳变，导致程序逻辑混乱。

如果你的外部电路已经有上拉或下拉电阻，那 MCU 这边就配成浮空输入，让外部电阻决定电平。比如很多传感器模块的输出脚已经带了上拉，你直接浮空输入就行。如果外部没有上下拉，那就得靠 MCU 内部的上下拉。按键检测是最典型的例子：按键一端接引脚，另一端接 GND，那引脚就配上拉输入，按键没按下时内部上拉让引脚保持高电平，按下时引脚被拉到 GND 变成低电平。

模拟输入是另一个特殊的存在。当你用 ADC 采集模拟信号时，引脚必须配成模拟输入。这个模式下，引脚的数字输入电路被关闭，信号直接进入 ADC 模块。如果你把 ADC 引脚配成了其他输入模式，数字电路会干扰模拟信号，采集出来的值会跳动得很厉害。

4.4 复用功能模式：什么时候需要它

复用输出模式是给外设用的。STM32 的很多引脚除了能做普通 GPIO，还能作为 USART、SPI、I2C、定时器等外设的引脚。当你把某个引脚配置成复用功能后，这个引脚就不再受 GPIO 数据寄存器控制了，而是由对应的外设来控制。

比如你要用 USART1 发送数据，PA9 是 TX 引脚，你就需要把 PA9 配成推挽复用输出。这样当你往 USART1 的数据寄存器写数据时，硬件会自动把数据串行化并从 PA9 发出去，你不需要手动去翻转 PA9 的电平。如果你错误地把 PA9 配成了普通推挽输出，那 USART 的数据就发不出来，因为引脚根本不听 USART 的指挥。

复用功能的选择还涉及到重映射。有些外设的引脚可以通过 AFIO 重映射到其他引脚上，比如 USART1 默认在 PA9/PA10，但可以重映射到 PB6/PB7。使用重映射之前需要使能 AFIO 时钟并调用GPIO_PinRemapConfig函数。这个功能在引脚冲突的时候特别有用，但重映射之后原来的引脚就不能再作为该外设使用了。

5. 实操：从零搭建一个 STM32 标准外设库工程

5.1 开发环境的选择与搭建

虽然现在 STM32CubeIDE 和 Keil MDK 都很流行，但如果你想真正理解从main到硬件的链路，我建议用标准外设库手动搭建一个工程。这个过程会让你被迫去了解启动文件、链接脚本、库文件依赖这些平时被 IDE 隐藏起来的东西。

开发环境我推荐 Keil MDK 5，配合 STM32F1 的标准外设库。Keil 的安装和芯片包安装这里不展开，重点讲工程搭建。你需要准备的东西有：STM32F10x 标准外设库压缩包、一个启动文件（根据芯片容量选startup_stm32f10x_md.s或hd.s）、以及 CMSIS 核心头文件。

工程目录我习惯这样组织：Startup放启动文件，CMSIS放内核相关文件，Library放标准外设库的inc和src，User放自己的main.c和中断处理文件，Output放编译产物。这样分目录的好处是结构清晰，换芯片或者升级库的时候不容易乱。

在 Keil 里新建工程后，需要把启动文件加入工程，设置头文件包含路径，定义芯片型号的宏（比如STM32F10X_MD和USE_STDPERIPH_DRIVER）。这两个宏很关键，前者告诉库文件你的芯片属于哪个容量等级，后者告诉库文件启用标准外设库。如果忘了定义，编译会报一堆找不到定义的错误。

5.2 时钟配置：被很多人忽略的关键一步

标准外设库的工程里，时钟配置通常在system_stm32f10x.c文件里，通过SystemInit函数完成。这个函数在启动文件里被调用，发生在main之前。默认情况下，它会把系统时钟配置成外部晶振倍频后的 72MHz（如果你的板子用的是 8MHz 晶振）。

但这里有一个坑：如果你的板子没有焊接外部晶振，或者晶振频率不是 8MHz，SystemInit里的配置就会失败，芯片会自动切回内部 8MHz 时钟。这时候你的串口波特率、定时器周期全都会不对，因为这些都是基于系统时钟计算的。我遇到过好几次串口乱码的问题，最后发现都是晶振配置和实际硬件不匹配。

所以我的习惯是，在main的开头加一句读取系统时钟的代码，把当前时钟频率通过串口打印出来确认。标准外设库提供了RCC_GetClocksFreq函数，可以获取各个总线的时钟频率。确认时钟正确之后，再往下做其他初始化。

5.3 GPIO 初始化的标准写法

GPIO 初始化是每个 STM32 项目都绕不开的步骤。标准外设库的写法分三步：使能时钟、定义结构体、调用初始化函数。

使能时钟这一步经常被忘记。STM32 的外设时钟默认是关闭的，你不使能时钟，写寄存器也没用。GPIOA 到 GPIOG 的时钟在 APB2 总线上，用RCC_APB2PeriphClockCmd使能。比如要点亮 PA5 上的 LED，就得先RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE)。

然后是定义GPIO_InitTypeDef结构体，设置GPIO_Pin、GPIO_Mode、GPIO_Speed三个成员。GPIO_Pin用GPIO_Pin_5这种宏，GPIO_Mode根据前面讲的八种模式选，GPIO_Speed在输出模式下才有效，一般选 50MHz 就行。最后调用GPIO_Init(GPIOA, &GPIO_InitStructure)完成配置。

配置完之后，就可以用GPIO_SetBits和GPIO_ResetBits来翻转引脚了。这两个函数本质上就是写 BSRR 寄存器，GPIO_SetBits写高 16 位，GPIO_ResetBits写低 16 位。用 BSRR 的好处是原子操作，不会被中断打断，比读改写 ODR 寄存器安全。

5.4 一个完整的 LED 闪烁程序拆解

把前面的东西串起来，一个完整的 LED 闪烁程序大概长这样：

#include "stm32f10x.h" void Delay(__IO uint32_t nCount) { for(; nCount != 0; nCount--); } int main(void) { GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_5; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStructure); while(1) { GPIO_SetBits(GPIOA, GPIO_Pin_5); Delay(500000); GPIO_ResetBits(GPIOA, GPIO_Pin_5); Delay(500000); } }

这段代码虽然简单，但每一行都有讲究。Delay函数用的是空循环，这种延时方式不精确，受编译器优化等级影响很大。如果开了-O2优化，编译器可能直接把空循环优化掉，导致延时失效。实际项目中应该用 SysTick 定时器来做精确延时，或者用定时器中断来翻转引脚。

GPIO_Mode_Out_PP是推挽输出，适合驱动 LED。如果你的 LED 是低电平点亮，那GPIO_SetBits是灭，GPIO_ResetBits是亮，别搞反了。GPIO_Speed_50MHz影响的是引脚翻转的上升沿和下降沿速度，速度越高电磁干扰越大，功耗也越高。如果只是驱动 LED，其实用 2MHz 就够了，没必要设成 50MHz。

6. 常见问题与排查技巧实录

6.1 程序下载后没反应，怎么一步步排查

程序下载进去没反应，是嵌入式开发中最常见也最让人抓狂的问题。我的排查顺序是这样的：先确认供电和晶振，再确认下载是否成功，然后确认时钟配置，最后才怀疑代码逻辑。

供电问题看起来很低级，但实际中经常遇到。有些开发板用 USB 供电，电流不够，芯片能下载但跑不起来。用万用表量一下 VDD 和 VSS 之间的电压，确认在 3.3V 左右。晶振问题也很常见，尤其是自己画的板子，晶振没起振或者负载电容不匹配，芯片会切到内部时钟，导致所有基于外部时钟的配置全部失效。

下载是否成功，不能只看 IDE 提示。有些时候 IDE 提示下载成功，但实际上芯片处于写保护状态，代码根本没写进去。可以用调试器读一下 Flash 的内容，看看是不是你的代码。如果用的是 ST-Link，可以在 Keil 的 Debug 模式下查看反汇编，确认main函数的地址和内容对不对。

时钟配置的确认方法前面提过了，通过串口打印RCC_GetClocksFreq的结果。如果串口本身就不通，那就先用调试器单步执行，看SystemInit执行完之后各个时钟寄存器的值。

6.2 GPIO 配置了但引脚没反应

GPIO 配置了但引脚没反应，通常有三个原因：时钟没使能、模式配错了、引脚被复用了。

时钟没使能是最常见的。STM32 的 GPIO 时钟默认关闭，你不调用RCC_APB2PeriphClockCmd，后面怎么配都没用。这个错误在初学者中特别普遍，因为编译不会报错，下载也正常，就是引脚不动。

模式配错也很常见。比如你要输出高电平驱动 LED，但配成了开漏输出，那高电平就是悬空的，LED 可能微亮或者不亮。或者你要读按键，但配成了浮空输入，外部又没有上下拉，读进来的值就是随机的。

引脚被复用是容易被忽略的原因。有些引脚在复位后默认就是复用功能，比如 JTAG 占用的 PA13、PA14、PA15、PB3、PB4。如果你想把这些引脚当普通 GPIO 用，需要先关闭 JTAG 功能，调用GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE)。这个坑我在用 PB3 做普通输出的时候踩过，查了半天才发现是 JTAG 占用了。

6.3 中断进不去或者频繁误触发

中断进不去，先检查 NVIC 配置。标准外设库用NVIC_Init配置中断优先级和使能，你需要设置NVIC_IRQChannel、NVIC_IRQChannelPreemptionPriority、NVIC_IRQChannelSubPriority、NVIC_IRQChannelCmd四个成员。优先级分组也要配置，用NVIC_PriorityGroupConfig设置。如果优先级分组没设对，抢占优先级和子优先级的位数分配就会出错，导致中断行为异常。

中断频繁误触发，通常是标志位没清除。比如外部中断，进入中断服务函数后必须清除 EXTI 的挂起位，否则中断会一直触发。串口接收中断也是，读了数据之后硬件会自动清除标志位，但如果你用的是查询方式而不是中断方式，标志位可能一直挂着。

还有一个隐蔽的问题：中断服务函数的名称必须和启动文件里的向量表一致。比如EXTI0_IRQHandler这个名字，你写成EXTI0_Handler或者大小写不对，编译器不会报错，但中断触发时会跳到一个默认的死循环里。这个错误在手动搭建工程时特别容易犯，因为启动文件里的名字是固定的，你得去对照。

6.4 常见问题速查表

7. 从标准外设库到 HAL 库的过渡思考

虽然这篇文章主要围绕标准外设库展开，但不得不承认，现在新项目用 HAL 库的越来越多。标准外设库已经停止更新，ST 官方主推 HAL 和 LL 库。如果你已经熟悉了标准外设库，过渡到 HAL 库其实不难，核心概念是相通的，只是 API 换了名字。

标准外设库的GPIO_Init在 HAL 库里变成了HAL_GPIO_Init，参数从结构体变成了GPIO_InitTypeDef指针，用法几乎一样。时钟使能从RCC_APB2PeriphClockCmd变成了__HAL_RCC_GPIOA_CLK_ENABLE宏。中断处理从直接写NVIC_Init变成了HAL_NVIC_SetPriority和HAL_NVIC_EnableIRQ。

最大的差异在于 HAL 库引入了句柄（Handle）的概念，外设初始化、读写、中断处理都围绕句柄展开。这个设计让代码更模块化，但也让初学者多了一层理解成本。我的建议是，先把标准外设库的寄存器操作逻辑搞清楚，再去看 HAL 库，你会发现 HAL 库只是把同样的操作包装得更规范了，底层的东西没变。

不管用哪个库，main函数的本质没有变：它是复位向量最终跳转到的入口，它必须包含一个永不退出的循环，它里面的初始化代码最终都是在配置寄存器。理解了这一点，换什么库都只是换汤不换药。

我个人在实际项目中的体会是，标准外设库适合学习和中小型项目，代码量小、执行效率高、对硬件的控制直接。HAL 库适合复杂项目和跨系列移植，抽象层次高、生态完善、配合 CubeMX 能快速搭建。两者没有绝对的好坏，关键看你的项目需求和团队的技术栈。如果时间允许，我建议两种都花点时间摸一遍，这样在看别人的代码或者接手老项目时，不会因为库不同就束手无策。