ESP32-P4 Windows环境搭建踩坑指南：从安装到烧录的8个坑

这块板子我盯了很久。ESP32-P4 第一次把乐鑫的芯片拉到了“高性能计算”这个档位：双核 RISC-V 主频拉到 400MHz 级别，带硬件图像处理、MIPI-CSI/DBI 接口、USB 2.0，还破天荒地不带 WiFi 和蓝牙。对这个定位，我的第一反应不是“能跑多快”，而是“这套环境得怎么搭”。ESP32-P4 在 Windows 上用 ESP-IDF 做环境搭建，一路下来踩的坑比我想象中多，而且很多坑是 ESP-IDF、Windows 和 P4 这颗新芯片三者叠加出来的，网上零星有帖子提到，但没人系统性整理过。这篇文章把我实际踩过的 8 个坑一个个拆开，每个都写清楚现象、原因、解决步骤和一些容易被忽略的细节。适合刚拿到 ESP32-P4 开发板、准备在 Windows 上正经搞开发的工程师，也适合被 ESP-IDF 安装器折腾到怀疑人生的新手。

1. 写在前面：ESP32-P4 与 Windows 环境搭建的“坑点地图”

先说说我为什么非要碰 ESP32-P4。这颗芯片的定位非常清楚：它不是替代 ESP32-S3 做物联网节点，而是瞄准 HMI 屏显、视觉识别、边缘 AI 推理这类需要算力和外设带宽的场景。没有无线模块这件事反而是个优点——减少了射频布线和认证负担，适合把它嵌进更复杂的系统里当“算力核心”，WiFi 交给 ESP32-C6 之类的协处理器去管。但这种定位也意味着，用 P4 的人通常不是刚接触嵌入式的小白，而是有明确产品需求的开发者。这类人对开发环境的要求就是：装得快、编译稳、烧录不折腾，偏偏 ESP32-P4 刚出来那阵子，在 Windows 上这三件事都容易翻车。

再解释一下 ESP-IDF 在 Windows 上的特殊性。ESP-IDF 严格说不是一个 IDE，而是一整套基于 CMake 的构建系统、工具链、Python 环境和乐鑫自己的命令行工具集合，官方针对 Windows 提供两种安装途径：在线安装器（esp-idf-tools-setup）和离线安装器。在线安装器理论上能自己把依赖一个个拉下来，实际跑起来很容易在某个中间步骤失败；离线安装器打包了 IDF 源码和工具链，但体积大、版本固定、更新麻烦。两种方式我都试过，最终的结论是：常规开发直接上离线安装器，哪怕多下载几个 G，也比在线安装器反复重试省时间。

我在安装过程中总结出一个总览表，这 8 个坑基本覆盖了从“下载安装器”到“看到第一条串口日志”的完整链路。先有个全局印象，后面逐个拆解。

这张表不是凭空列出来的，是我在一周内反复 clean install 了三遍、踩出来的真实路径。接下来按安装期、编译期、烧录期三个阶段细说。

2. 安装期实战：从下载到环境变量生效的 4 个坑

2.1 坑 1：在线安装器反复失败，下载像在抽卡

现象：从官网下载esp-idf-tools-setup并双击运行，前面几步选择组件倒是顺利，一到真正下载 ESP-IDF 源码和工具链阶段，进度条走走停停，最后弹红字，常见的有Network error、Download failed、Failed to fetch data from URL之类。重试几次，可能换了一个组件继续失败，也可能在某一步彻底中断。日志文件里能看到它其实在同时下载很多个 URL 来源，包括 GitHub、乐鑫自己的服务器和一些 Python 包索引地址，任何一个源抽风，整个安装就中止。

原因：在线安装器的逻辑是“最小化下载”，你选了哪些芯片支持，它就把对应的工具链、GCC 交叉编译器和 OpenOCD 等组件一个个拉回来。这些组件分布在多个不同的远程仓库，没有做统一的镜像切换选项，对网络环境不友好。尤其是安装到一半断网或者 DNS 抖动，重试机制做得也不好，很难续传。

解决：没有再跟在线安装器死磕，换成官方离线安装包（esp-idf-tools-setup-offline）。离线包把 ESP-IDF 源码、Python 环境、工具链、OpenOCD、GCC 等全部打在一个包里，安装过程基本等同于解压+配置环境变量，不再从网上拉依赖，成功率几乎 100%。离线包的下载体积确实大，但比在线版本反复失败的体验好太多。

补充一个细节：离线包安装时同样会询问安装目录和 IDF 目标芯片选择，这里我建议把“安装目录”选在纯英文、无空白的路径下，比如D:\esp-dev\esp-idf。别看这一步简单，坑 4 会提到路径问题，提前规避能省很多事。安装完成后，正常情况下桌面会出现ESP-IDF Command Prompt快捷方式，这个快捷方式会执行 IDF 自带的初始化脚本，是后续命令行操作的最靠谱入口。

2.2 坑 2：Python 与 pip 源不配合，依赖安装报一堆红字

现象：安装过程中或安装完成后执行idf.py --version，突然报出一长串 Python 异常，常见的提示是ModuleNotFoundError，或者安装 Python 包时出现ERROR: Could not find a version that satisfies the requirement ...、No matching distribution found。

原因：ESP-IDF 自带了一个 Python 虚拟环境，正常情况下它会在安装时自动创建在~/.espressif/python_env/下，并且所有依赖都装进这个虚拟环境。但 Windows 上如果用户之前已经装过 Python，并且把系统 Python 的 Scripts 目录写进了 PATH，IDF 的安装脚本偶尔会识别错 Python 解释器，导致依赖装到了系统 Python 里，或者直接因为 pip 源访问慢而安装失败。另一个常见情况是 Python 版本不匹配，新版 IDF 要求 3.9 以上，如果系统 Python 是 3.7 或 3.8，就会报版本不兼容。

解决：最省心的做法是检查 IDF 工具目录里的 Python 环境是否完整。打开ESP-IDF Command Prompt，先执行：

python --version

如果输出不是 IDF 自带虚拟环境的 Python 版本，而是系统的 Python，说明环境变量没有切对。此时不要手动去改全局 PATH，而是直接检查idf_cmd_init.bat是否正确指向了安装时生成的 Python。更快的绕行方案：删除系统 PATH 里的 Python 条目，或者把 IDF 的 Python 环境路径显式排在 PATH 最前面。至于 pip 下载慢的问题，可以在%USERPROFILE%\pip\pip.ini里配置一个国内镜像源，这是完全合法的提速手段：

[global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple trusted-host = pypi.tuna.tsinghua.edu.cn

配好之后，重新用ESP-IDF Command Prompt执行idf.py --version，正常的话会输出版本号和用到的 Python 路径。顺便说一句，很多教程让新手直接在系统 Python 里pip install esptool，这其实是额外引入冲突的根源，我后来统一使用 IDF 自带的工具链，系统 Python 只当作普通脚本解释器用，再没因为这个出过问题。

2.3 坑 3：idf.py 命令找不到，环境变量不生效

现象：安装全部完成，按教程打开 Windows 自带的 CMD 或者 PowerShell，输入idf.py --version，系统提示“不是内部或外部命令”。这时候很多人第一反应是环境变量没配好，于是自己去“系统属性 -> 环境变量”里一顿操作，把 ESP-IDF 的路径加进 PATH，结果打开新终端依旧找不到。

原因：ESP-IDF 的设计根本不希望你把它加进全局 PATH。idf.py的有效性依赖一系列环境变量，包括IDF_PATH、IDF_TOOLS_PATH、IDF_PYTHON_ENV_PATH等，这些变量由export.bat或idf_cmd_init.bat脚本动态设置。官方安装器生成的“ESP-IDF Command Prompt”快捷方式，本质上就是在启动终端时先执行这个脚本，再显示命令行。而普通 CMD 默认不会执行这个初始化，所以命令找不到太正常了。

解决：不要自己手动设置全局永久环境变量。正确的打开方式是用桌面生成的ESP-IDF Command Prompt快捷方式，进入命令行后再执行idf.py。如果你更习惯用 VS Code 或其他终端，也可以在普通 CMD 里手动初始化：

C:\esp-dev\esp-idf\export.bat

执行完这个脚本，IDF 相关的路径和变量就会注入到当前终端，idf.py自然就能用了。

这里有一个很容易被忽略的经验：同一个终端窗口不要重复执行export.bat，因为它会把 PATH 越加越长，某些情况下会导致命令重复或者参数过长报错。每次开新窗口做一次初始化就够。还有一个衍生问题，如果你在普通 CMD 里不初始化就执行idf.py flash，即使烧录工具能跑，也会因为IDF_PATH没生效而找不到工程下的配置。碰到这种情况，第一步永远是回到ESP-IDF Command Prompt里重新初始化环境，而不是折腾全局 PATH。整个环境搭建流程里，这一条是“会了就能省半小时”的关键经验。

2.4 坑 4：路径里的中文/空格/特殊字符惹的祸

现象：IDF 安装成功，初始化没问题，但新建工程并执行idf.py set-target esp32p4时，编译脚本里面某一步突然报错，提示找不到GCC可执行文件，或者报一个很隐晦的No such file or directory，路径里还带着乱码。查遍工具链目录都正常，就是编译过不去。

原因：ESP-IDF 的工具链和 Python 脚本对路径中的非 ASCII 字符兼容性并不好，尤其是中文、空格、括号这类字符。Windows 下的 CMD 和 MSYS2 工具链在解析路径时，编码处理方式不一致，工具链拿到一个带中文的路径，可能直接失败。这个问题其实老生常谈，但偏偏很多人装环境时习惯用“我的文档”、“桌面”下的文件夹，或者直接解压到C:\Program Files\这种带空格的路径下，于是踩坑。

解决：统一约定所有与 ESP-IDF 相关的路径都用纯英文、无空格、无特殊字符。我自己用的结构是：

D:\esp-dev\ ├─ esp-idf\ # IDF 源码 ├─ tools\ # IDF 工具链目录 └─ projects\ # 自己的工程目录

Windows 用户直接把这套目录结构放在非系统盘的根级目录下，基本能避开 90% 的路径问题。另一个相关细节是 Windows 用户名如果包含中文，%USERPROFILE%路径里会有中文，这会影响~/.espressif目录的创建。解决办法是设置IDF_TOOLS_PATH环境变量指向一个纯英文目录（比如D:\esp-dev\tools），安装器和后续的工具链就会把.espressif下的内容放到这个目录，而不是用户目录下。我最初踩的坑就是这个：用户名是中文，导致idf.py build时 clang/python 一直报错，改成显式环境变量后一次性通过。

3. 编译期实战：从第一个工程到第一条日志的 4 个坑

3.1 坑 5：改了 target 却不知道 P4 需要新版本 IDF

现象：拿到别人分享的 ESP32-P4 工程，或者自己idf.py create-project新建工程后，执行idf.py set-target esp32p4，提示：

Unknown target 'esp32p4'

或者编译到一半，链接脚本报错，Kconfig 文件里依赖的符号找不到。有人会以为是自己命令拼错了，反复查idf.py set-target的帮助信息，甚至怀疑开发板坏了。

原因：ESP-IDF 对芯片的支持是“版本绑定”的。ESP32-P4 这颗芯片是 Cortex-A 之外的 RISC-V 新架构，需要比较新的 IDF 版本才认识它，老版本（比如 5.2 或更早）里根本没有esp32p4这个 target 定义。我只用官方离线包默认带的版本，就掉进了“版本太旧”的坑里。

解决：直接用ESP-IDF Command Prompt执行：

idf.py --version

如果版本号低于 v5.4，建议不要在这个环境上硬刚，直接下载包含 ESP32-P4 的更新安装包，或者更新 IDF 到 release 分支。确认版本没问题后，再执行：

idf.py set-target esp32p4

这时候输出里会显示Target: ESP32P4，然后才开始生成 sdkconfig。 顺便说一下，ESP32-P4 因为没有 WiFi，很多示例工程默认的sdkconfig里会包含网络相关的配置选项，但这不是编译报错的原因。如果你是从 ESP32-S3 工程的默认配置直接set-target切换过来，有可能会遇到某些组件因为 target 改变而自动裁剪，这个不需要手动干预，IDF 会重新生成配置。真正需要注意的反而是以下几点：

1. 切换 target 之前，最好把旧的sdkconfig备份一下，某些自定义配置在切换后可能被覆盖。
2. 如果工程是在旧版本 IDF 上创建的，切换版本后建议先idf.py fullclean，再重新构建，避免编译缓存里的旧产物干扰。
3. ESP32-P4 的某些外设驱动（比如 MIPI-DSI、USB 2.0）需要单独在 menuconfig 里使能，属于正常现象，不是环境坏了。

一个快速验证环境是否支持 P4 的命令：

idf.py --list-targets

如果列表里能看到esp32p4，说明这版 IDF 没问题。

3.2 坑 6：第一次编译就卡在子模块下载/组件拉取

现象：环境看起来一切正常，set-target也通过了，高高兴兴执行idf.py build，结果编译进度条刚开始一格，就卡住不动，或者报一个类似fatal: unable to access 'https://github.com/...': Failed to connect的错误。再盯久一点，日志里会出现组件管理器（component manager）正在解析依赖、下载软件包的内容，卡在这个阶段，进度纹丝不动。

原因：IDF 5.x 之后引入了组件管理器，很多组件（比如esp32-camera、lvgl、某些 LCD 驱动）不再强制随 IDF 源码一起发布，而是在构建时从组件注册表动态拉取。组件注册表默认在海外服务器，Windows 下如果网络不稳定，解析依赖时就会卡住。另外，IDF 本身用 Git 管理子模块，首次检出时也要拉一批子模块仓库。

解决：首先要区分卡住的位置。看日志里是否有Downloading component字样，如果有，说明是组件管理器在拉注册表里的内容。此时可以去工程目录下用idf.py menuconfig打开配置，找到组件管理器相关的下载设置，或者直接设置 IDF 的镜像前缀：

idf.py build

组件管理器原生支持环境变量IDF_COMPONENT_REGISTRY_URL和IDF_COMPONENT_OVERLOAD_URL，如果网络上有可用的镜像服务，可以通过设置这个环境变量指向镜像。国内环境下直接把关键词“esp idf component manager mirror”搜一下，就能找到社区维护的镜像地址，配置方式是：

set IDF_COMPONENT_REGISTRY_URL=https://your-mirror-url

如果卡的是 Git 子模块，用乐鑫在 Gitee 上维护的镜像仓库替换ESP-IDF源码来源也是常规做法。比如从https://github.com/espressif/esp-idf.git换成https://gitee.com/EspressifSystems/esp-idf.git，克隆速度会明显改善。但要注意，换镜像源要保证 IDF 版本一致，避免混合不同来源的仓库导致 Git 状态混乱。 实际过程中，我建议做一个“预拉取”操作：拿到一个新工程后，先不要直接build，而是先执行：

idf.py reconfigure

这一步会提前解析并下载所有需要的组件，把网络依赖消耗在构建开始之前。如果这一步顺利通过，后面的build就纯粹是本机编译行为，不会再出现中途卡死的状况。这个习惯帮我避开了很多次“编译到一半去喝水，回来看它还在转圈”的尴尬。

3.3 坑 7：烧录连不上板子，串口/JTAG 驱动没装好

现象：编译已经通过，生成了build/esp32p4_demo.bin，插上开发板，执行idf.py -p COM3 flash，结果烧录界面一直停留在等待连接状态，输出重复显示：

Connecting........_

或者干脆报could not open port COM3: FileNotFoundError。这个时候很多人一脸懵——明明编译都过了，板子也有供电，USB 线也插了，怎么就是连不上。

原因：ESP32-P4 开发板跟经典的 ESP32-DevKitC 不一样。很多 P4 板子默认用的是板载 USB-JTAG/串口复合设备，需要 Windows 安装对应的驱动，或者说 Windows 识别成了其他类型。芯片原生的USB-Serial/JTAG控制器在 Windows 下有时会显示为一个USB Composite Device，而不是直接的COM端口，这样一来idf.py flash自然找不到串口。另外，不同厂商的 P4 开发板桥接芯片不同，有 CP210x、有 CH340，也有直接用 USB-JTAG 的，驱动没装全就会出现这种情况。

解决：第一步打开“设备管理器”，展开“端口 (COM 和 LPT)”看有没有带感叹号的设备。如果看到一个未知设备或“USB 串行设备”，先把开发板重新插拔一次，再看看是否多出一个 COM 口。如果根本没有 COM 口，就要根据手上的板子安装对应驱动。常见组合如下：

如果你用的是 ESP32-P4 官方或第三方开发板，可以先用乐鑫提供的esp-idf驱动安装工具来装 USB-JTAG 驱动，在ESP-IDF Command Prompt里执行：

python -m esptool "chip" -p COM? "get_chip_info"

但前提是驱动已经识别出 COM 口。更稳妥的方式：安装最新的 CP210x 驱动，然后再看看设备管理器里是否出现COM端口。装完驱动后，还有一个容易忽略的事项：USB-JTAG 模式下如果串口监视器也在占用同一个端口，idf.py flash会提示端口被占用。把终端里执行的idf.py monitor先关掉，再烧录，基本能解决。

我个人的习惯是安装完驱动后，在设备管理器里右键该端口，选择“属性”，把端口号的“COM3”之类的改成高一点的值（比如 COM10），这能避开某些 IDE 逻辑上对低端口号的默认占用。听起来很玄学，但 Windows 下 COM3 被蓝牙虚拟串口占用的概率确实不是零，这一步很值得做。

3.4 坑 8：杀毒软件和系统防护把工具链当成恶意文件

现象：编译进行到 GCC 编译某个源文件时，终端突然报一个类似Permission denied或Cannot create file的错误，或者 VSCode 里跳出来一串“文件已被隔离”的提示。更迷惑的是，过一会儿发现整个编译失败，但重新执行idf.py build时提示工具链找不到，路径下的xtensa-esp32-elf或riscv32-esp-elf文件夹莫名其妙少了文件。

原因：Windows 自带的「病毒和威胁防护”实时扫描，以及很多国内第三方杀毒软件，会对riscv32-esp-elf、openocd这类工具目录里的可执行文件产生误报。这些文件本质上是交叉编译器和调试器，带有大量命令行参数和文件操作逻辑，容易触发启发式查杀。被杀毒软件隔离之后，工具链文件直接从磁盘消失，编译环境当场废掉。

解决：在安装完 ESP-IDF 工具链后，第一时间把整个IDF_TOOLS_PATH目录（比如D:\esp-dev\tools）加入杀毒软件的排除列表。Windows Defender 的排除路径在“设置 -> 隐私和安全性 -> 病毒和威胁防护 -> 管理设置 -> 排除项”里添加。国产安全软件类似，一般在设置界面能找到“白名单”或“信任区”入口。第三方杀软如果不给目录直接排除，甚至可以暂时把实时防护关闭一小段时间，编译完成后再恢复，但我不推荐长期关闭，工具链目录排除就够用。

除了杀毒软件，还有另一个 Windows 的防护功能容易踩：内存完整性（Core Isolation 下的内存隔离）在部分机器上会导致某些工具链运行时崩溃，典型表现是编译过程中进程直接中断，偶尔出现一条 Windows 错误提示。如果你编译时随机闪退，并且在事件查看器里能看到System Guard或Hypervisor相关的错误，可以考虑将内存完整性暂时关闭后再试。但这是一个权衡操作，建议只在出现确切问题时空隙性关闭，平时保持开启。 还有一个隐藏的坑：Windows 的电源计划在“节能”模式下可能给 CPU 降频，导致大工程编译时休眠或响应慢，进而引发工具链超时。我在编译大规模工程时会把电源计划切到“高性能”，不是为了玄学，而是减少不可控的性能波动。这一步虽然不是环境搭建本身的问题，但“编译卡死”这个表象很容易让人误以为是环境问题。

4. ESP32-P4 的验证链路：从空工程到串口打印

踩完上面 8 个坑，环境基本就稳定了。但“能用”不等于“确认可用”，我建议花十分钟跑一个完整的验证链路，确保后面做项目时不会被环境问题拖后腿。

打开ESP-IDF Command Prompt，创建一个空工程：

idf.py create-project p4_hello cd p4_hello idf.py set-target esp32p4

创建一个main目录下的 C 文件，写一个最简单的点灯循环加串口打印：

#include <stdio.h> #include "freertos/FreeRTOS.h" #include "freertos/task.h" #include "driver/gpio.h" #include "esp_log.h" #define BLINK_GPIO GPIO_NUM_21 static const char *TAG = "p4_hello"; void app_main(void) { gpio_set_direction(BLINK_GPIO, GPIO_MODE_OUTPUT); while (1) { gpio_set_level(BLINK_GPIO, 1); ESP_LOGI(TAG, "LED ON"); vTaskDelay(pdMS_TO_TICKS(500)); gpio_set_level(BLINK_GPIO, 0); ESP_LOGI(TAG, "LED OFF"); vTaskDelay(pdMS_TO_TICKS(500)); } }

注意：这里 GPIO 号码不一定是 21，要看你手上板子的 LED 实际接在哪个引脚上。如果找不到板载 LED，可以跳过点灯部分，只保留ESP_LOGI打印，只要能烧录并看到串口输出，环境就算验证过了。编译命令：

idf.py build

首次编译时间会久一些，取决于 CPU 性能，正常情况下 1 到 3 分钟。编译结束后接上开发板，运行：

idf.py -p COMx flash monitor

如果能在串口监视器里看到LED ON / LED OFF的循环日志，整条链路就算打通了。之后做 LVGL、摄像头或 USB 项目时，有一些 ESP32-P4 特有的编译选项需要留意：

• 官方推荐把sdkconfig.defaults里加上CONFIG_IDF_TARGET_ESP32P4=y
• 如果用了外部 PSRAM，检查CONFIG_SPIRAM=y和对应型号配置
• P4 的 USB 2.0 外设驱动（比如 USB Host）在 menuconfig 里需要单独使能
• 做视觉应用时，MIPI-CSI 的驱动和 DMA 缓存大小跟传统 ESP32 不同，先跑官方 camera 例程再改自己的代码

这些选项如果有疑问，直接在idf.py menuconfig里搜索关键词，比翻 PDF 文档快得多。

5. 常见问题速查表与我的避坑习惯

为了把这次环境搭建的经验变成可复用的东西，我把遇到的问题和排查路径整理成一张速查表，遇到报错可以先对号入座。

这张表只能解决“表面问题”，真正能让人少走弯路的，是下面这几个我长期坚持的习惯：

第一，永远不要手动把 ESP-IDF 塞进系统全局 PATH。IDF 是一种多版本可切换的环境，全局 PATH 会让不同版本的项目互相干扰。我见过同事的机器上同时有两套 IDF，结果idf.py指向的是旧版，新工程的编译错误排查了半天，最后发现是环境连接到错的工具链。用官方快捷方式或者export.bat就是在做版本隔离，看似多一步，实际是省心。

第二，每个工程都单独保留一份.venv或 IDF 的 Python 虚拟环境依赖。虽然 IDF 本身已经创建了虚拟环境，但不同工程可能依赖不同版本的额外组件。我习惯在工程根目录用requirements.txt记录额外依赖，并用idf.py python作为解释器来安装，这样不会污染全局环境。

第三，拿到新板子后不要急着烧复杂工程，先跑一个 GPIO 点灯。这一步能快速确认串口驱动、烧录工具、芯片 target 三个变量是否都正确。如果点灯都过不了，后边的摄像头、屏显、USB 项目只会更难排查。很多新手环境配好了，却因为一个烧录步骤没过，就走了无数弯路。

第四，针对 Windows 特有的系统干扰，我建立了一个“编译时段”共识：编译大型工程时，暂时关闭第三方杀毒软件的实时监控，或者至少把D:\esp-dev\tools下的所有子目录加入白名单。Windows Defender 的排除列表也可以一并配置。一次配置，长期受益。

6. 写在最后

表达一个个人体会：ESP32-P4 确实是乐鑫把产品线往上探了一大步的标志性芯片，但它的工具链和生态成熟度比 ESP32-S3 还是差一截。环境搭建的难，本质上是因为新芯片 + 新 IDF 版本 + Windows 的路径编码和驱动隔离机制，三者叠加出来的“时间差问题”。碰到问题不要怀疑自己，先对照报错信息判断是网络问题、路径问题还是驱动问题，再决定操作方向——大部分踩坑都是因为这三个问题叠在一起，让人误以为是自己把环境彻底装坏了。

踩过几次坑之后，我现在反而更推荐在 Windows 上使用“双通道方案”：日常写代码和编辑用 VS Code 加 ESP-IDF 扩展，真正构建和烧录还是回到ESP-IDF Command Prompt里执行命令行。不是因为 IDE 不好用，而是命令行环境更容易隔离变量、更容易看到完整日志。省下的时间用来多跑几个外设驱动例程，比纠结于“哪种终端更优雅”要有价值得多。

最后再分享一个小技巧：每次装完 IDF、确认环境可用后，拿磁盘镜像工具把整个D:\esp-dev目录做一个压缩快照，放到移动硬盘或者 NAS 里。这个快照省去了以后换电脑、重装系统后重新折腾的时间。毕竟，环境搭建这个东西，你用它的最终目的，永远是赶紧进入写逻辑和调外设的正题，而不是和安装器缠斗。