简介：围绕STM32CubeMX图形化配置界面整理的docx文档，面向刚接触STM32、ARM嵌入式硬件与单片机开发的初学者及需要快速梳理配置流程的工程师，重点解决外设初始化、时钟设置与代码生成环节上手难的问题。文档以界面功能为主线，讲解时钟树、GPIO、ADC/DAC、UART、SPI、I2C等常用外设配置，并涉及Serial Wire调试接口搜索定位、中断与定时器设置、Keil MDK/IAR EWARM/GCC等开发环境代码生成。压缩包仅含1个docx文件，大小约443KB，便于直接查阅和随项目归档。已有344人学习，可作为配置界面速查与入门梳理材料，帮助读者理解各配置项作用、减少手动编写初始化代码的工作量，并为后续外设调试和项目开发建立清晰框架。
1. 打开 CubeMX 的第一屏：三个分区决定你后面 80% 的返工
拿到一块新板子，很多人第一反应是直接开工程写 main 函数，结果烧进去发现时钟不对、串口乱码、调试器连不上。STM32CubeMX 存在的意义，就是在写第一行用户代码之前，把 arm 内核、外设时钟、引脚复用这些底子先用图形界面钉死，再吐出一套能直接编译的初始化代码。它是 STM32 系列单片机开发里绕不开的入口工具，做嵌入式硬件和底层固件的同学基本都要过这一关。
这一屏界面看起来花哨，实际就三块：左边外设与引脚列表，中间芯片引脚图，右边外设参数面板，顶上还有个搜索框。后面所有的玄学问题，几乎都能在这三块里找到源头。下面按「先认路、再配调试口、再上时钟、最后落外设」的顺序拆，适合刚接手 STM32 的新手照着点，也适合已经会点灯但总在返工的人对一遍参数。
2. 搜索框与 Serial Wire：调试口配错，第一次上电就是黑匣子
2.1 搜索框的三种命中结果与使用姿势
CubeMX 左上角那个输入框，是整块界面里使用频率最高、也最容易被忽略的控件。输入关键字回车后，下拉列表里的结果大致分三类：外设名（比如 USART1、TIM2、ADC1）、引脚号（比如 PA9、PB6）、信号名（比如 USART1_TX、SYS_JTMS-SWDIO）。点中任意一条，中间的引脚图会跳到对应位置并把目标引脚高亮，右边的参数面板同步切到该外设。
这个行为决定了它的正确用法：先搜信号名，再搜外设名，最后才搜引脚号。因为信号名是「功能视角」，比如你搜USART1_TX，它会直接告诉你这个功能当前落在哪个引脚上、有没有被别的外设占用；而搜引脚号是「物理视角」，只能看到一个孤零零的脚，还得自己去判断能不能复用。新手最常干的事是搜 PA9 然后手动把它设成 GPIO_Output，结果后面一开 USART1 就撞车——本来那根线就是默认的串口发送脚。
搜索还有一个隐蔽的坑：外设没使能时，它的信号名搜不出来。比如你想找I2C1_SCL，但 I2C1 在左侧列表里还是灰色未激活状态，搜索框里敲进去可能一条结果都没有。这时候得先去 Connectivity 分类下把 I2C1 的 Mode 从 Disable 改成 I2C，再回来搜。这个顺序反了会让人以为软件出问题，实际是设计如此。
提示：搜索结果里带
SYS_前缀的信号，基本都是内核调试与系统级功能，改动它们之前先确认调试器还能不能连上板子。
2.2 SYS 面板里 Serial Wire 到底占哪两根线
Serial Wire 是 ARM 内核自带的两线调试接口，在 CubeMX 里由 System Core 分类下的 SYS 面板控制。把 Debug 下拉框从默认值改成Serial Wire之后，芯片图上 PA13 和 PA14 会立刻变成保留状态，对应的信号名分别是SYS_JTMS-SWDIO和SYS_JTCK-SWCLK。
这里要理解选型理由：完整的 JTAG 要占五根线（TMS、TCK、TDI、TDO、nTRST），而 Serial Wire 只占两根，PA13 走数据、PA14 走时钟，省下来的三个脚可以拿去做 GPIO 或者别的复用功能。对于引脚紧张的小封装型号，这个差别很实际。代价是调试通道从并行变成串行，烧写和单步的速度会慢一点，日常开发基本感知不到。
生成的 .ioc 文件里，这两根线的记录长这样，可以直接用文本编辑器打开核对：
# 摘自工程 .ioc 文件，调试口占用的引脚与信号名 Mcu.Pin19=PA13 Mcu.Pin20=PA14 PA13.Signal=SYS_JTMS-SWDIO PA14.Signal=SYS_JTCK-SWCLK逻辑说明：Mcu.PinNN是引脚的序号槽位，PA13.Signal才是真正的功能绑定。参数说明：序号槽位的数字在不同工程里会变，不要靠它做判断，认Signal这一行就行。如果你在代码仓库里看到有人手工改过这段，基本可以判定他经历过一次调试器连不上的事故。
同一面板下还有一项Timebase Source，默认是 SysTick。如果你的工程后面要挂 FreeRTOS，建议在这里改成某个基本定时器（比如 TIM6），原因在避坑章节展开。
2.3 引脚颜色与冲突提示怎么读
引脚图上每个脚都有颜色，这是 CubeMX 最直观的反馈机制，但很多人只记住了「绿色是好的」，剩下的靠猜。
绿色代表该引脚已经被某个外设或 GPIO 功能占用，且没有冲突。黄色是警告，常见于两种情况：一是外设只配了一半，比如 UART 开了但模式还没选完；二是复用功能存在电气上的注意事项，需要你点开引脚详情确认。红色是硬冲突，同一根引脚被两个不同外设同时要求使用，此时生成代码会失败或者生成出错误配置。
判断冲突的正确姿势不是盯颜色，而是点开右侧面板下方的引脚列表，按引脚号排序看一遍。红色的处理方式只有两种：换引脚，或者关掉其中一个外设。CubeMX 有时会自动帮你找替代引脚，但自动分配的结果不一定是 PCB 上真正走线的那一根，尤其在做硬件定型阶段，一定要对着原理图逐个核对。
还有一种情况是引脚被 SYS 的调试功能锁定，你想把它配成普通 GPIO 却点不动。这不是 bug，是软件在保护你——一旦把 SWDIO 改成推挽输出，下次上电调试器大概率连不上，只能靠「复位时连接」这种抢救手段。真要用这两根脚，就在 SYS 里把 Debug 改成No Debug，然后接受「以后可能得靠串口烧录」的现实。
3. 时钟树从 8MHz 推到 168MHz：PLL 五个参数怎么填才不报红
3.1 时钟树界面的四段结构
点开 Clock Configuration 标签，看到的是一张从左往右流动的图。把它拆成四段理解，就不会被密密麻麻的方框吓到。
第一段是时钟源：HSI 是内部高速 RC，HSE 是外部晶振，LSI 和 LSE 是低速那一套，分别喂给看门狗和 RTC。第二段是 PLL 倍频器，输入可以选 HSI 或 HSE，经过 M 分频、N 倍频、P 分频、Q 分频之后输出系统时钟。第三段是 AHB 预分频，把 SYSCLK 分频成 HCLK，也就是内核跑的主频。第四段是 APB1 和 APB2 预分频，分别喂给挂在这两条总线上的外设。
界面上每个方框的颜色也有含义：绿色是当前生效且合规，蓝色是可选项（点一下就能切换输入源），红色是超限。红色不一定代表填错了，有时候是上游还没配完导致的连锁反应，从上往下顺着改就能消掉。
选外部晶振还是内部 RC，是第一个要做的决定。HSE 精度高，串口波特率、USB、CAN 这些对时钟敏感的外设基本都得靠它；HSI 省两根引脚和一颗晶振，但温漂大，做产品时一般只在成本极度敏感且对时序没要求的场合用。我一般默认开 HSE，把晶振频率按原理图上的实际值填进Input frequency那一栏，8MHz 是最常见的。
3.2 以 8MHz 晶振推 168MHz 的填参过程
以 F4 系列常见的 168MHz 目标为例，把每一步的取值和约束列出来，照着填就能从红变绿。
| 参数 | 取值 | 约束与说明 |
|---|---|---|
| HSE 输入频率 | 8 MHz | 按板上晶振实际值填，填错后面全错 |
| PLL Source | HSE | 选外部晶振作为 PLL 输入 |
| PLLM（分频） | 8 | 8MHz / 8 = 1MHz，需落在 1~2MHz 推荐区间 |
| PLLN（倍频） | 336 | 1MHz × 336 = 336MHz，需落在 VCO 输出允许范围内 |
| PLLP（系统分频） | 2 | 336MHz / 2 = 168MHz，即 SYSCLK |
| PLLQ（USB 等分频） | 7 | 336MHz / 7 = 48MHz，供 USB 使用 |
| AHB 预分频 | 1 | HCLK = 168MHz，等于内核主频 |
| APB1 预分频 | 4 | 42MHz，不超过该总线上限 |
| APB2 预分频 | 2 | 84MHz，不超过该总线上限 |
填的时候有个顺序技巧：先定 HSE 频率，再定 PLLM 让 VCO 输入落到 1~2MHz，然后调 PLLN 把 VCO 输出拉到目标区间，最后用 PLLP 除出 SYSCLK。反过来从目标主频倒推，容易在 PLLM 上卡住，因为很多人不知道 VCO 输入是有下限的，8MHz 直接进 PLL 会报警。
APB1 那一格的 42MHz 值得单独说一句。F4 系列里 APB1 的外设总线上限通常就是 42MHz，而挂在上面的定时器时钟并不是 42MHz，而是总线频率的两倍（预分频不为 1 时）。也就是说，APB1 上的定时器实际跑在 84MHz。这个规则直接影响后面定时器的 PSC 和 ARR 计算，算错了定时周期就整体差一倍。
生成的时钟配置代码，核心就是那几个结构体赋值加一句校验：
/* CubeMX 生成的 SystemClock_Config 关键片段，保留判断分支便于定位 */ RCC_OscInitTypeDef RCC_OscInitStruct = {0}; RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE; RCC_OscInitStruct.HSEState = RCC_HSE_ON; /* 外部晶振起振 */ RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON; RCC_OscInitStruct.PLL.PLLM = 8; /* 8MHz / 8 = 1MHz */ RCC_OscInitStruct.PLL.PLLN = 336; /* VCO = 336MHz */ RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2; /* SYSCLK = 168MHz */ RCC_OscInitStruct.PLL.PLLQ = 7; /* 48MHz 给 USB */ if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK) { Error_Handler(); /* 晶振没起振会停在这里，先查焊接和负载电容 */ }逻辑说明：HAL_RCC_OscConfig会按结构体去写 RCC 寄存器并等待就绪标志，返回非 OK 说明晶振没起来或者参数超限。参数说明：PLLM是输入分频，写 8 表示除以 8，不是「8 倍」；PLLP用的是宏RCC_PLLP_DIV2，不能直接填数字 2，这一点手工改代码时特别容易错。
3.3 生成后怎么验证时钟真的跑对了
配置全绿不等于板子真跑在这个频率上。晶振虚焊、负载电容不匹配、HSE 起振慢，都会让程序卡在Error_Handler里或者悄悄退回 HSI。验证手段有三个层次。
最直接的是在调试器里看寄存器：打开 RCC 外设窗口，读CFGR的 SW 位段，确认当前系统时钟源是 PLL 而不是 HSI；再读PLLCFGR，核对 M、N、P、Q 四个位段和你填的值一致。
第二个办法是用 MCO 引脚把时钟输出到示波器上。在 Clock Configuration 里找到 MCO 那一栏，选 SYSCLK 并设置分频（比如除以 4），然后在引脚图上把 MCO 对应的脚配成复用推挽，用示波器量频率。这个方法直观，能同时验证「配置生效」和「实际频率准确」，缺点是得分一个引脚出来。
第三个办法是软件层面自测：用 SysTick 或者一个已知时钟源的定时器做 1 秒延时翻转 LED，拿逻辑分析仪量周期。如果实际周期是理论值的 1/2 或者 2 倍，八成是 APB 定时器时钟那个「×2 规则」算漏了。这类偏差靠肉眼看 LED 是看不出来的，必须上仪器。
4. GPIO 与串口面板：把点灯和 printf 落到可编译的参数上
4.1 GPIO 面板的六项参数逐个说
在芯片图上点某个引脚，选GPIO_Output，右侧 System Core → GPIO 面板里就会多出一行。这行展开后有六项要填，每一项都影响最终生成的初始化代码。
第一项GPIO output level是上电初始电平，选 Low 还是 High 取决于你的 LED 是低电平点亮还是高电平点亮，配反了会出现「上电瞬间闪一下」的现象。第二项GPIO mode选Output Push Pull还是Output Open Drain，推挽能主动输出高低电平，开漏只能拉低、高电平靠外部上拉，驱动共阳数码管或者做电平转换时才用开漏。
第三项GPIO Pull-up/Pull-down，输出模式下一般选 No pull，输入模式下这个选项才关键：按键接地下拉、接电源上拉，悬空不接会有随机跳变。第四项Maximum output speed分四档，从 Low 到 Very High，速度越高边沿越陡、EMI 越大，点个 LED 用 Low 就够，跑 SPI 高速信号才需要往上调。
第五项User Label是最有价值的一项，填个LED_RUN之类的名字，生成的代码里会自动出现同名宏定义，后续写业务代码不用再记 PA5 这种编号。第六项在输入模式下才会出现，是外部中断的触发边沿配置，上升沿、下降沿、双边沿三选一。
/* CubeMX 生成的 GPIO 初始化片段，User Label 会变成宏 */ __HAL_RCC_GPIOA_CLK_ENABLE(); /* 先开 GPIOA 时钟，漏了这步引脚不响应 */ GPIO_InitStruct.Pin = LED_RUN_Pin; /* 宏来自 User Label */ GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(LED_RUN_GPIO_Port, &GPIO_InitStruct); HAL_GPIO_WritePin(LED_RUN_GPIO_Port, LED_RUN_Pin, GPIO_PIN_RESET); /* 初始电平 */逻辑说明：先使能端口时钟再配置寄存器，这是所有 STM32 GPIO 操作的固定顺序；HAL_GPIO_WritePin放在初始化末尾，保证上电瞬间电平就是你想要的状态。参数说明：LED_RUN_Pin和LED_RUN_GPIO_Port都是 CubeMX 自动生成的宏，改了 User Label 之后重新生成，宏名会跟着变，但你自己代码里引用旧宏的地方不会自动改，这是编译报错的高发点。
4.2 UART、SPI、I2C 的 Mode 选择与引脚复用
Connectivity 分类下这三个是嵌入式里最常用的通信外设，界面结构类似：先选 Mode，再配参数，引脚自动分配。
UART 的 Mode 一般选Asynchronous（异步），同步模式要额外一根时钟线，用得少。选完之后 PA9 和 PA10 会自动变成绿色，分别对应 TX 和 RX。参数区里 Baud Rate 填 115200 是常态，Word Length 8 位、Parity None、Stop Bits 1，这套组合就是俗称的 8N1。硬件流控Hardware Flow Control默认关，除非你的对端设备明确要求 RTS/CTS，否则开了会多占两根引脚还不通。
SPI 的 Mode 要区分Full-Duplex Master、Full-Duplex Slave和只读的Receive Only Master。做主设备时重点在 Parameter Settings 里的Clock Polarity（CPOL）和Clock Phase（CPHA），这两个组合出四种 SPI 模式，必须和从设备手册对上。配错了的现象是数据能发出去但读回来全是 0xFF 或者错位，很多人第一反应是接线问题，实际是模式不匹配。
I2C 的 Mode 选I2C就是标准模式或快速模式，速度在参数里调，100kHz 是安全值，400kHz 需要上拉电阻配合。引脚上 I2C 是开漏结构，CubeMX 会自动把引脚配成开漏复用，不需要你手动改。
/* 串口中断接收的最小闭环：CubeMX 只生成初始化，接收逻辑要自己写 */ uint8_t rx_byte; void StartReceive(void) { HAL_UART_Receive_IT(&huart1, &rx_byte, 1); /* 每次收 1 字节，收完进回调 */ } void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART1) { HAL_UART_Transmit(&huart1, &rx_byte, 1, 10); /* 原样回显，10ms 超时 */ HAL_UART_Receive_IT(&huart1, &rx_byte, 1); /* 必须重新挂接收，否则只收一次 */ } }逻辑说明：HAL_UART_Receive_IT是「挂一次收一次」，回调里如果不重新调用，第二次数据就进不来，这个坑几乎每个人都踩过。参数说明：最后一个参数是超时时间，单位毫秒，发送时给太小会在波特率低的时候丢数据；接收的第三个参数是期望字节数，填 1 表示收满一个字节就触发回调，填更大的数则要收满才触发，做协议解析时通常配合空闲中断一起用。
SPI 和 I2C 在 CubeMX 里能配出来的只是初始化，真正的读写时序得自己写或者接 HAL 的阻塞/中断/DMA 接口。界面能帮你省掉的是时钟使能、引脚复用、波特率寄存器计算这些机械活，协议层的逻辑一行都省不掉。
4.3 NVIC 与定时器：中断优先级和 PSC/ARR 怎么定
中断配置在 NVIC 面板里，每个外设的中断线单独一行，勾上Enabled才真正开。抢占优先级（Preemption Priority）和子优先级（Sub Priority）的数值越小优先级越高，规则是：抢占优先级高的可以打断正在执行的低的，子优先级只在同时挂起时决定谁先跑，不能抢占。
新手常犯的错是把所有中断都设成 0，结果串口和定时器互相打断，出现数据错位。合理的做法是按实时性排序：通信类（串口、SPI）给中高优先级，定时器节拍给中，按键、LED 这类人机交互给最低。优先级分组在 NVIC 面板顶部的Priority Group里选，一般用默认的 4 位抢占 0 位子优先级就够。
定时器的配置在 Timers 分类下。以 TIM2 产生 1ms 中断为例，Clock Source 选Internal Clock，然后填两个值：
| 参数 | 取值 | 说明 |
|---|---|---|
| Prescaler (PSC) | 83 | 定时器时钟 84MHz / (83+1) = 1MHz |
| Counter Period (ARR) | 999 | 1MHz / (999+1) = 1000Hz，即 1ms |
| auto-reload preload | Enable | 改 ARR 时下一周期生效，避免撕裂 |
| NVIC 中断 | 勾选 TIM2 global | 不勾就永远不会进中断函数 |
计算公式是「定时器时钟 ÷ (PSC+1) ÷ (ARR+1) = 中断频率」，其中定时器时钟要按前面说的 APB 规则来：APB1 分频不为 1 时，定时器时钟是 APB1 频率的两倍。这一条如果漏掉，实际周期会正好差一倍，而且现象很迷惑——代码看着没错，就是时间不对。
/* 定时器中断回调，CubeMX 生成的是弱函数，这里重写 */ void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance == TIM2) { static uint32_t tick = 0; tick++; /* 1ms 自增，做软件定时基准 */ if (tick % 500 == 0) /* 每 500ms 翻转一次 LED */ { HAL_GPIO_TogglePin(LED_RUN_GPIO_Port, LED_RUN_Pin); } } }逻辑说明：回调函数里只做标志位和轻量动作，耗时逻辑放到主循环，不然会拖慢整个中断响应。参数说明：htim->Instance用来区分是哪个定时器触发的，工程里有多个定时器时必须判断，否则会互相干扰；tick用 static 修饰保证跨调用保持，但要注意它在中断上下文里自增，主循环读取时最好加个临界区保护。
5. 避坑排查：CubeMX 里五个最容易翻车的现场
5.1 现象：程序烧进去之后调试器再也连不上
原因通常是把 SYS 的 Debug 设成了No Debug，或者手工把 PA13、PA14 配成了普通 GPIO 输出。代码一跑起来就把 SWD 引脚改成了推挽输出，调试通道当场断掉，之后再上电，调试器根本抢不到那两根线。
解决办法是把调试器的连接方式改成「复位时连接」（Connect under Reset），让它在芯片复位释放前的那几毫秒里抓住 SWD 口，连上之后立刻擦除整片 Flash。血泪经验是：动手改 PA13/PA14 之前，先在代码里留一个长延时或者按键判断，给自己留条后路。更彻底的做法是不用这两根脚，换封装或者换引脚分配。
5.2 现象：改了时钟树，编译出来的程序还是老频率
原因多半是生成路径和工程路径不一致。CubeMX 生成代码时可以选择「生成到独立文件夹」还是「覆盖当前工程」，如果 Keil 里打开的是另一个目录下的副本，你改的那个 .ioc 根本没被编译进去。
排查方式是打开工程目录，看Core/Src/main.c里SystemClock_Config的 PLLN 值是不是你刚填的那个数。对不上就说明生成路径错了，回到 CubeMX 的 Project Manager 页核对Application Structure和Toolchain/IDE设置。我一般把生成目录和 IDE 工程目录固定成同一个，避免这种双份文件的糊涂账。
5.3 现象：每次重新生成，自己写的业务代码就没了
原因是代码写在了main.c的USER CODE BEGIN和USER CODE END之外。CubeMX 靠这两组注释标记来保护用户代码，标记之外的部分每次生成都会被整段覆盖。
正确的做法是把业务函数放到独立的.c/.h文件里，只在这个文件里调用；如果非要在 main.c 里写，务必写在/* USER CODE BEGIN 2 */和/* USER CODE END 2 */之间。同时把「保留用户代码」相关的选项开着，生成前先提交一次版本，翻车了还能回退。
5.4 现象：接了 FreeRTOS 之后 HAL_Delay 卡死
原因是 FreeRTOS 默认把 SysTick 抢过去做调度时基，而 HAL 库的延时也依赖 SysTick 的计数，两边打架。表现是任务里调用 HAL_Delay 后整个系统不再调度，或者延时时间严重不准。
解决办法是在 SYS 面板把Timebase Source从 SysTick 改成任意一个基本定时器（TIM6、TIM7 都行），让 HAL 用独立的定时器计时，SysTick 留给调度器。改完之后 CubeMX 会自动生成对应的HAL_InitTick重定向代码，不用手写。
5.5 现象：引脚冲突报红，或者搜索框找不到想要的信号
前者通常是同一个外设的两个实例抢同一组引脚，或者某个引脚被 SYS 的调试功能锁定。处理时按引脚号排序看一遍列表，逐个确认是哪个外设在占用。
后者是外设还没使能，信号名自然不会出现在搜索结果里。顺序必须是「先使能外设 → 再搜信号 → 再确认引脚」。另外工程路径里带中文或空格也会导致代码生成阶段报错，这类问题跟 CubeMX 本身无关，但报错信息很难读，容易误判成软件故障。路径统一用英文加下划线，是我这些年最省事的一条规矩。
6. 工程生成与 .ioc 管理：让配置成为唯一真源头
真正把 CubeMX 用顺的人，最后都会把注意力从界面上挪到那个.ioc文件上。它是一份纯文本的配置清单，记录了每个引脚的功能、每个外设的参数、时钟树的每一级分频。把.ioc提交到版本控制，就等于把「这块板子为什么这么配」这件事固定下来了，后面换人接手、换电脑重装环境，双击打开就能还原全部设置。
我的习惯是每个工程只保留一份.ioc，放在仓库根目录，生成目录和 IDE 工程目录都用相对路径指过去。.ioc里有一行ProjectManager.ProjectFileName，指向 IDE 工程文件名，这一行和实际文件名对不上时，生成会跑到别的目录去，所以重命名工程时这两处要一起改。
二次打开工程时有个细节值得说：CubeMX 检测到.ioc版本比当前软件新时会提示「工程由更高版本创建」，此时强行打开可能丢失部分参数。团队协作时最好统一软件大版本，或者在新版本里打开后立刻另存一份，别在原文件上直接改。
最后一个技巧跟验证有关。每次改完配置生成代码，别急着写业务逻辑，先编译一遍，再烧进去用调试器看三个地方：RCC 的CFGR确认时钟源，GPIO 的MODER确认引脚模式，NVIC 的ISER确认中断真的开了。这三项对上了，后面的外设调试才有意义；对不上就先回去查配置，别在业务代码里瞎找。
从那以后我每次点下「Generate Code」之前，都会强制走一遍「存盘、提交、确认生成路径」这三步。看着麻烦，但比事后从一堆被覆盖的文件里找回业务代码要轻松得多。希望帮到你。
本文还有配套的精品资源，点击获取
