1. 为什么我劝你尽早把STM32开发环境从MDK5迁到PlatformIO搞STM32的兄弟大概率都有过这样的经历新装一台电脑第一件事就是翻出MDK5的安装包然后开始找注册机、找License、找器件支持包折腾大半天环境还没跑通。更别提MDK5那个上古时代的编辑器界面代码补全基本靠猜跳转定义经常失灵用久了真的会让人怀疑自己是不是在2024年写代码。我最早也是MDK5的重度用户从F103一路做到F407工程建了不下几十个。但后来项目里开始混用ESP32、GD32、甚至一些国产RISC-V芯片MDK5的局限性就暴露得非常明显了——它只擅长ARM Cortex-M这一亩三分地换个平台就得换一套工具链学习成本和维护成本都在叠加。后来我全面转向了VSCode PlatformIO这套组合说实话回不去了。PlatformIO本质上是一个跨平台的嵌入式开发框架它把编译器、调试器、烧录工具、库管理全部封装成一套统一的配置体系你只需要在platformio.ini里写几行配置剩下的它全帮你搞定。而VSCode作为编辑器代码补全、跳转、Git集成、终端、远程开发这些能力都是现成的体验比MDK5强了不止一个档次。这篇文章我打算把STM32F103C8T6这颗经典芯片在PlatformIO下的完整开发环境搭建流程讲透包括标准库的配置方式。为什么强调标准库因为网上大部分PlatformIO教程默认用的是HAL库或者Arduino框架但很多从MDK5转过来的朋友手里积累了大量标准库代码直接扔掉太可惜。而且标准库对于F103这种资源有限的芯片来说代码体积更小、执行效率更高学习底层寄存器的逻辑也更直观。这套方案适合谁如果你手上有一块STM32F103C8T6最小系统板想摆脱MDK5的束缚或者你刚入门STM32不想一上来就折腾License问题又或者你同时玩多种芯片想要一套统一的开发环境——那这篇内容应该能帮你省下不少试错时间。2. 环境搭建前的整体思路与工具选型2.1 为什么是PlatformIO而不是Keil或CubeIDE先说说工具选型的逻辑。嵌入式开发环境的核心诉求无非几个编译要快、调试要稳、库管理要方便、跨平台要支持。MDK5在编译和调试上确实成熟但它的生态是封闭的器件支持包要单独下载库管理基本靠手动拷贝。STM32CubeIDE虽然免费但它是基于Eclipse改的那个卡顿感用过的人都懂而且它强绑定HAL库对标准库的支持并不友好。PlatformIO的优势在于它的抽象层次设计得很合理。底层它调用的是arm-none-eabi-gcc这套开源工具链编译质量完全没问题中间层它用Python脚本管理构建流程支持几千种开发板上层它和VSCode深度集成你几乎感觉不到自己在用一个框架。最关键的是PlatformIO的库管理是声明式的你在配置文件里写一行lib_deps它自动帮你下载、解析依赖、配置头文件路径这个体验是MDK5完全给不了的。还有一个容易被忽略的点PlatformIO天然支持多环境配置。同一个项目里你可以定义多个env比如一个用于F103C8T6一个用于F407VET6切换的时候只需要在VSCode底部点一下不用改任何代码。这在做产品多版本维护的时候特别香。2.2 标准库在PlatformIO下的定位这里要澄清一个概念PlatformIO官方对STM32的支持主要是通过stm32cube框架也就是HAL库和arduino框架。标准库并不在官方框架列表里但这不代表不能用。标准库本质上就是一堆C文件和头文件只要你把编译路径和宏定义配对GCC照样能编。我选择标准库的原因有三个。第一代码体积可控。HAL库为了通用性加了很多抽象层一个简单的GPIO翻转编译出来可能比标准库大好几倍F103C8T6只有64KB Flash省着点用很重要。第二寄存器操作直观。标准库的函数命名和寄存器手册对应得很紧密比如GPIO_SetBits(GPIOA, GPIO_Pin_0)你一看就知道它在操作哪个寄存器的哪个位对理解硬件很有帮助。第三存量代码复用。网上大量F103的例程、项目、毕设代码都是基于标准库的直接迁移过来能省很多事。当然标准库也有它的局限比如ST官方已经停止更新了新芯片支持不好。但对于F103C8T6这颗国民芯片来说标准库的成熟度完全够用甚至可以说是最合适的选择。2.3 整体搭建流程概览整个环境搭建可以拆成几个阶段先装VSCode和PlatformIO插件这是基础然后准备标准库文件这是核心接着创建PlatformIO工程并配置platformio.ini这是关键最后写一个LED闪烁的测试程序验证环境这是收尾。听起来步骤不多但每一步都有坑。比如PlatformIO默认会去下载HAL库你得想办法让它用你的标准库比如标准库的启动文件和链接脚本需要和PlatformIO的构建系统对接再比如烧录方式的选择ST-Link、串口ISP、DAPLink各有各的配置方法。这些细节我会在后面逐一展开。3. VSCode与PlatformIO的安装配置实操3.1 VSCode安装与基础插件配置VSCode的安装没什么好说的去官网下载对应系统的安装包一路下一步就行。Windows下建议勾选添加到PATH这样在终端里可以直接用code命令打开项目。安装完成后我建议先做几件事设置中文界面如果你习惯中文的话、配置字体和主题、开启自动保存。插件方面除了PlatformIO本身我强烈建议装这几个C/C微软官方的提供代码补全和跳转、GitLens看代码提交历史很方便、Better Comments注释高亮、Hex Editor查看bin文件。如果你还要写Python脚本处理数据那Python插件也装上。这里有个细节要注意PlatformIO插件自带了一个C/C的配置它和微软官方的C/C插件有时候会打架导致头文件路径识别错误。我的做法是在PlatformIO项目里以PlatformIO的配置为准如果出现红色波浪线但能正常编译那就不用管它是IntelliSense的索引问题重启一下VSCode或者重新加载窗口通常能解决。3.2 PlatformIO插件安装与首次初始化在VSCode的扩展面板里搜索PlatformIO IDE认准那个蚂蚁图标的安装。安装过程会稍微有点久因为它要下载PlatformIO Core一堆Python包和工具链。国内网络环境下可能会卡在下载工具链这一步这时候可以配置一下镜像源。安装完成后VSCode左侧会出现一个蚂蚁头图标那就是PlatformIO的主页。第一次打开它会自动初始化下载编译器和调试工具。这个过程可能需要几分钟到十几分钟取决于网络。如果卡住了可以打开终端手动执行pio pkg install看看具体卡在哪。初始化完成后你可以点击PIO Home里的Platforms标签搜索ST STM32确认这个平台已经安装。如果没有点进去安装一下。这个平台包含了STM32系列的所有构建脚本和工具链配置是后面创建工程的基础。3.3 工具链与烧录工具的确认PlatformIO安装STM32平台的时候会自动下载arm-none-eabi-gcc工具链和openocd调试工具。你可以在~/.platformio/packages/目录下看到它们。Windows下路径通常是C:\Users\你的用户名\.platformio\packages\。烧录工具方面我手头用的是ST-Link V2便宜好用淘宝十几块钱一个。PlatformIO对ST-Link的支持很好配置里写upload_protocol stlink就行。如果你用的是串口ISP烧录那需要配置upload_protocol serial并且要手动让芯片进入Bootloader模式BOOT0接高电平复位然后BOOT0接回低电平。DAPLink的话upload_protocol cmsis-dap。提示ST-Link的驱动在Windows下可能需要手动装一下去ST官网下载ST-Link Utility或者STM32CubeProgrammer安装后驱动就带上了。如果设备管理器里能看到ST-Link并且没有黄色感叹号那就没问题。4. STM32标准库在PlatformIO下的配置全流程4.1 标准库文件的获取与目录结构规划标准库的获取有几个途径。最正规的是去ST官网下载STM32F10x_StdPeriph_Lib_V3.5.0这是最后一个版本也是用得最广的。不过ST官网现在下载需要注册账号稍微有点麻烦。另一个途径是从一些开源项目或者GitHub仓库里找很多开发者把标准库整理好了放在上面。下载下来之后你会看到这样的目录结构Libraries文件夹下有STM32F10x_StdPeriph_Driver外设驱动、CMSIS内核相关Project文件夹下有各种例程和模板Utilities下是评估板的驱动一般用不到。在PlatformIO项目里我建议这样组织目录项目根目录/ ├── platformio.ini ├── src/ │ └── main.c ├── lib/ │ └── STM32F10x_StdPeriph_Driver/ │ ├── inc/ │ └── src/ ├── startup/ │ └── startup_stm32f10x_md.s ├── cmsis/ │ ├── core_cm3.h │ ├── stm32f10x.h │ └── system_stm32f10x.c └── ldscript/ └── stm32f103c8t6.ld把标准库的inc和src放到lib目录下PlatformIO会自动把lib下的所有源文件加入编译。CMSIS的核心头文件和系统文件单独放一个目录启动文件和链接脚本也单独放。这样结构清晰后面维护起来方便。4.2 platformio.ini核心配置逐行解析platformio.ini是整个项目的灵魂所有构建、烧录、调试的配置都在这里。下面是我常用的一个配置模板逐行解释[env:stm32f103c8t6] platform ststm32 board bluepill_f103c8 framework stm32cube upload_protocol stlink debug_tool stlink build_flags -D STM32F10X_MD -D USE_STDPERIPH_DRIVER -I cmsis -I lib/STM32F10x_StdPeriph_Driver/inc -I startup build_src_filter ../lib/STM32F10x_StdPeriph_Driver/src/*.c ../cmsis/system_stm32f10x.c ../startup/startup_stm32f10x_md.s board_build.ldscript ldscript/stm32f103c8t6.ldplatform ststm32指定了平台board bluepill_f103c8是开发板型号这个型号对应的是F103C8T6最小系统板。framework stm32cube这里虽然写的是stm32cube但我们通过build_flags和build_src_filter覆盖了默认的源文件选择实际编译的是标准库。build_flags里的-D STM32F10X_MD是告诉编译器这是中容量产品F103C8T6属于中容量64KB Flash-D USE_STDPERIPH_DRIVER是启用标准库驱动。后面的-I是头文件搜索路径。build_src_filter是关键它告诉PlatformIO哪些源文件要参与编译。默认情况下PlatformIO会编译src目录下的文件我们用../lib/...把标准库的源文件加进来。注意路径是相对于src目录的。board_build.ldscript指定链接脚本这个脚本定义了Flash和RAM的起始地址、大小以及各个段怎么摆放。F103C8T6的Flash是64KB起始地址0x08000000RAM是20KB起始地址0x20000000。4.3 启动文件与链接脚本的适配要点启动文件是芯片上电后执行的第一段代码它负责初始化堆栈指针、设置中断向量表、调用SystemInit、最后跳转到main。标准库的启动文件是汇编写的文件名一般是startup_stm32f10x_md.smd代表中容量。这里有个坑标准库的启动文件默认是给Keil或者IAR用的语法和GCC不完全兼容。你需要找GCC版本的启动文件或者自己改一下。GCC版本的启动文件在ST的例程里通常放在GCC目录下文件名类似startup_stm32f10x_md.s但内容不一样。链接脚本也是类似的情况。Keil用的是.sct分散加载文件GCC用的是.ld链接脚本。你需要一个针对F103C8T6的GCC链接脚本。这个脚本的核心内容是MEMORY { FLASH (rx) : ORIGIN 0x08000000, LENGTH 64K RAM (rwx) : ORIGIN 0x20000000, LENGTH 20K } SECTIONS { .text : { . ALIGN(4); *(.isr_vector) *(.text) *(.rodata) . ALIGN(4); _etext .; } FLASH .data : { . ALIGN(4); _sdata .; *(.data) . ALIGN(4); _edata .; } RAM AT FLASH .bss : { . ALIGN(4); _sbss .; *(.bss) . ALIGN(4); _ebss .; } RAM }这个脚本定义了Flash和RAM的布局以及.text、.data、.bss三个段的摆放规则。.data段比较特殊它的初始值存在Flash里运行时拷贝到RAM所以有AT FLASH这个标记。注意链接脚本里的LENGTH一定要和芯片实际资源匹配。F103C8T6是64KB Flash、20KB RAM如果你用的是F103C6T6Flash只有32KB那就要改成32K。写大了编译能过但烧录会出问题写小了浪费资源。4.4 中断向量表与系统时钟配置中断向量表在启动文件里定义它是一张函数指针数组每个中断源对应一个入口。标准库的启动文件里已经定义好了所有中断的弱符号weak symbol你在C代码里重新定义一个同名函数就会覆盖掉弱符号这就是中断服务函数的注册方式。系统时钟配置在system_stm32f10x.c里默认的SystemInit函数会把时钟配到72MHz使用外部8MHz晶振。如果你板子上的晶振不是8MHz或者你想用内部RC振荡器就需要改这个文件。F103C8T6最小系统板一般都是8MHz晶振所以默认配置就能用。这里有个细节system_stm32f10x.c里有一堆宏定义比如SYSCLK_FREQ_72MHz你需要确保对应的宏是打开的。默认情况下这个文件会根据STM32F10X_MD这个宏来选择配置所以只要build_flags里定义对了一般不用改。5. 从零创建工程到点亮第一颗LED5.1 创建PlatformIO工程并导入标准库在VSCode里按CtrlShiftP打开命令面板输入PlatformIO: New Project然后填写工程名、选择开发板搜索bluepill或者STM32F103C8、选择框架随便选一个后面会改。创建完成后你会得到一个标准的PlatformIO工程结构。接下来把前面准备好的标准库文件、CMSIS文件、启动文件、链接脚本按照4.1节的目录结构放进去。然后修改platformio.ini填入4.2节的配置内容。保存后PlatformIO会自动重新加载配置。这时候你可以点一下VSCode底部的Build按钮那个对勾图标看看能不能编译通过。如果报错说找不到头文件检查build_flags里的-I路径对不对如果报错说找不到源文件检查build_src_filter里的路径。路径问题是最常见的多试几次就熟了。5.2 编写LED闪烁测试程序环境配好后写一个最简单的LED闪烁程序验证。F103C8T6最小系统板上一般有一个板载LED接在PC13上低电平点亮。代码如下#include stm32f10x.h void Delay(__IO uint32_t nCount) { for(; nCount ! 0; nCount--); } int main(void) { GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE); GPIO_InitStructure.GPIO_Pin GPIO_Pin_13; GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_PP; GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOC, GPIO_InitStructure); while (1) { GPIO_SetBits(GPIOC, GPIO_Pin_13); Delay(8000000); GPIO_ResetBits(GPIOC, GPIO_Pin_13); Delay(8000000); } }这段代码的逻辑很直白开GPIOC的时钟配置PC13为推挽输出然后在主循环里翻转电平。Delay函数是个简单的忙等待8000000这个值是我实测在72MHz下大概能产生0.5秒左右的延时具体值可以根据需要调整。编译通过后点Upload按钮烧录。如果ST-Link连接正常你会看到板子上的LED开始闪烁。到这一步环境就算跑通了。5.3 编译、烧录与调试的完整验证编译的时候注意看终端输出PlatformIO会打印出编译了哪些文件、占用了多少Flash和RAM。F103C8T6的Flash是64KB一个LED闪烁程序大概占用2-3KBRAM占用1KB左右。如果你看到Flash占用突然变得很大那可能是把不需要的标准库文件也编进去了可以在build_src_filter里排除掉。烧录的时候ST-Link需要连接SWD接口SWCLK、SWDIO、GND、3.3V四根线。有些板子还需要接复位线但一般不用。烧录成功后终端会显示SUCCESS。调试方面PlatformIO支持GDB调试。在VSCode里按F5启动调试可以设断点、单步执行、查看变量和寄存器。这个体验比MDK5的调试器好很多尤其是查看外设寄存器的时候VSCode的界面更清爽。实操心得如果烧录时报target not found或者no device found先检查ST-Link的驱动和连线。有时候是SWD速率太高导致通信不稳定可以在platformio.ini里加一行upload_speed 1000000把速率降下来试试。6. 常见问题排查与避坑经验实录6.1 编译报错类问题速查报错信息可能原因解决方法fatal error: stm32f10x.h: No such file头文件路径没配检查build_flags里的-I路径undefined reference to SystemInit没编译system_stm32f10x.c在build_src_filter里加上这个文件region FLASH overflowedFlash空间不够检查链接脚本的LENGTH或者精简代码cannot find -lstdc工具链不完整重新安装PlatformIO的STM32平台multiple definition of xxx重复定义检查是否有同名文件被编译了两次编译类问题大部分是路径和宏定义的问题。我的经验是先把build_flags和build_src_filter打印出来看看确认路径拼写正确。PlatformIO的终端里可以用pio run -v查看详细的编译命令能看到实际传给GCC的参数对排查很有帮助。6.2 烧录与连接类问题排查烧录问题最常见的就是连不上芯片。先确认硬件ST-Link的SWDIO接PA13SWCLK接PA14GND对接3.3V对接。如果板子是从外部供电的ST-Link的3.3V可以不接但GND必须接。软件方面检查platformio.ini里的upload_protocol和debug_tool是否配置正确。如果用的是山寨ST-Link有时候需要降速加upload_speed 500000试试。还有一种情况是芯片被读保护了需要先解锁用STM32CubeProgrammer连一下解除读保护再烧录。串口ISP烧录的话需要把BOOT0接高电平按复位然后烧录烧录完再把BOOT0接回低电平再复位。这个流程比较繁琐建议还是用ST-Link。6.3 标准库特有的坑与解决方案标准库在GCC下编译有几个特有的坑。第一个是__weak关键字Keil下用__weakGCC下要用__attribute__((weak))。标准库的GCC版本已经处理好了但如果你从Keil工程移植代码可能会遇到这个问题。第二个是内联汇编的语法差异。Keil用的是ARMCC的内联汇编格式GCC用的是ATT格式两者不兼容。标准库里用到内联汇编的地方主要是__disable_irq、__enable_irq这些GCC版本的标准库已经用CMSIS的函数替代了一般不用改。第三个是printf重定向。Keil下用fputc重定向到串口GCC下需要实现_write函数。这个在调试的时候很有用可以打印变量值到串口助手。int _write(int file, char *ptr, int len) { for (int i 0; i len; i) { while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) RESET); USART_SendData(USART1, ptr[i]); } return len; }避坑技巧如果你从MDK5移植标准库工程到PlatformIO建议先把启动文件和链接脚本换成GCC版本的然后逐个文件编译遇到报错再针对性修改。不要一次性全搬过来那样报错太多会很难定位。6.4 性能与资源占用的优化建议F103C8T6的资源有限优化很重要。编译的时候加-Os优化等级可以减小代码体积在build_flags里加-Os就行。但要注意-Os有时候会优化掉一些看似没用的代码比如空的延时循环这时候可以用__IO修饰变量或者用__NOP()指令。标准库的stm32f10x_xxx.c文件里有很多条件编译只编译你用到的外设可以减小体积。比如你只用GPIO和USART那就在build_src_filter里只加stm32f10x_gpio.c和stm32f10x_usart.c其他的不加。但要注意依赖关系比如USART可能依赖GPIO和RCC这些也要加上。RAM的优化主要是减少全局变量和大的数组。如果RAM不够用可以把一些常量数据放到Flash里用const修饰。栈的大小也可以在启动文件里调整默认是1KB如果用了递归或者大的局部数组可能需要加大。7. 从MDK5迁移到PlatformIO的实战建议7.1 工程文件与源码的迁移策略从MDK5迁移到PlatformIO最省事的做法是保留原有的源码结构只替换构建系统。具体来说把MDK5工程里的.c和.h文件按功能分类放到PlatformIO的src和lib目录下。启动文件和链接脚本换成GCC版本然后配置platformio.ini。MDK5的工程文件.uvprojx是XML格式的里面记录了源文件列表、头文件路径、宏定义、编译选项等信息。你可以手动把这些信息翻译到platformio.ini里。源文件列表对应build_src_filter头文件路径对应build_flags里的-I宏定义对应-D编译选项对应build_flags里的其他参数。如果工程比较大手动翻译太累可以写个Python脚本解析.uvprojx自动生成platformio.ini。这个脚本不难写用xml.etree.ElementTree解析就行。我写过一版大概一百多行能处理大部分情况。7.2 编译选项与宏定义的对应关系MDK5的编译选项和GCC的编译选项不是一一对应的需要做一些转换。比如MDK5的-O0对应GCC的-O0-O1对应-O1但-Ospace和-Otime在GCC里没有直接对应一般用-Os和-O2替代。宏定义方面MDK5里常用的USE_STDPERIPH_DRIVER、STM32F10X_MD这些在GCC下是一样的直接搬过来就行。但有些MDK5特有的宏比如__CC_ARM在GCC下要改成__GNUC__。标准库的代码里有很多这样的条件编译GCC版本的标准库已经处理好了但如果你自己写的代码里有就需要改。还有一个容易忽略的点MDK5默认使用MicroLIB这是一个精简版的C库GCC下没有直接对应。如果你用了printf、malloc这些函数GCC下需要链接newlib或者newlib-nano。PlatformIO默认用的是newlib-nano体积小适合嵌入式。7.3 调试体验的差异与适应MDK5的调试器功能很强大尤其是外设寄存器查看和逻辑分析仪。PlatformIO的调试基于GDB和OpenOCD功能上稍微弱一些但日常调试够用。VSCode的调试界面可以查看变量、调用栈、断点也可以查看寄存器但外设寄存器的可视化不如MDK5直观。不过PlatformIO有一个优势是多平台统一。你可以在同一个VSCode窗口里调试STM32、ESP32、甚至Linux程序调试快捷键和界面都是一样的。这种一致性带来的效率提升长期来看是值得的。如果你确实需要查看外设寄存器可以装一个VSCode插件叫Cortex-Debug它提供了外设寄存器的可视化查看功能配置一下SVD文件就能用。SVD文件在ST的官网或者CMSIS包里能找到放到项目里在launch.json里配置一下路径就行。7.4 团队协作与版本管理的优势从团队协作的角度看PlatformIO比MDK5强太多了。MDK5的工程文件是二进制或者XMLGit diff基本看不出什么有用信息合并冲突更是灾难。PlatformIO的platformio.ini是纯文本所有配置一目了然Git diff清清楚楚。而且PlatformIO的库管理是声明式的lib_deps里写清楚依赖的库和版本团队成员拉下代码后PlatformIO自动下载对应版本的库不会出现我这里能编译你那里编译不过的情况。MDK5的库管理基本靠手动拷贝版本混乱是常态。还有一点PlatformIO支持CI/CD集成。你可以在GitHub Actions里配置自动编译每次提交代码自动跑一遍编译确保没有破坏构建。这个在MDK5下很难做到因为MDK5是商业软件CI环境里装不了。8. 我在这套环境上踩过的几个真实坑第一个坑是启动文件的选择。我一开始用的是Keil版本的启动文件编译报了一堆汇编语法错误。后来换成GCC版本的才通过。这个坑的本质是ARMCC和GCC的汇编语法不兼容Keil的启动文件用的是ARMCC语法GCC不认。第二个坑是链接脚本的RAM大小。我一开始抄了一个F103C8T6的链接脚本但那个脚本写的是20KB RAM而我的板子实际上是20KB没问题。但后来换了一块国产替代的板子RAM只有20KB但链接脚本写的是20KB编译能过但运行不稳定。后来查手册才发现有些国产替代芯片的RAM实际可用大小和标称有差异链接脚本要留点余量。第三个坑是ST-Link的固件版本。我手头有一个很老的ST-Link V2固件版本太旧PlatformIO的OpenOCD不认。后来用STM32CubeProgrammer升级了固件才正常。如果你遇到连不上芯片的情况先检查一下ST-Link的固件版本。第四个坑是标准库的assert_param。标准库默认开启了参数断言每个库函数入口都会检查参数合法性这会增加代码体积和运行时间。在Release版本里可以关掉在build_flags里加-D NDEBUG就行。但调试阶段建议开着能帮你发现一些参数错误。第五个坑是VSCode的IntelliSense。PlatformIO的头文件路径和VSCode的C/C插件有时候不同步导致代码里一堆红色波浪线但实际能编译。解决方法是打开命令面板运行C/C: Edit Configurations (UI)在Include Path里手动加上标准库的路径。或者干脆忽略波浪线只要编译能过就行。这套环境我用了快两年从F103到F407从标准库到HAL库从ST-Link到DAPLink各种组合都试过。总体来说PlatformIOVSCode的体验是碾压MDK5的尤其是对于需要多平台开发的场景。唯一的门槛是初始配置稍微复杂一点但配好之后就是一劳永逸。如果你还在犹豫要不要迁移我的建议是花一个下午把环境搭起来后面省下的时间绝对不止一个下午。