串口能识别板子，仍可能因为工具链、启动模式或供电导致烧录失败。分层检查比反复点击更有效。
本文使用经典 ESP32、ESP-IDF v2.1 与隔离低压演示电路。ESP-IDF（乐鑫开发框架）版本会改变接口与工具链。本文固定早期开发环境，GPIO 编号、电压和外设复用按具体开发板原理图核对，不把板子排针顺序当芯片引脚编号。
1. 从现象推到机制
编译把源码与目标配置生成固件，烧录写入闪存，复位后启动代码再运行应用。下载模式与正常启动状态不同，串口日志能区分程序没启动和启动后崩溃。
图中的四个节点分别表示源码构建、闪存写入、正常启动、串口观察。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
固定 v2.1 的 Xtensa 工具链与示例，设置串口后先编译 hello_world。下面是旧版 make 工作流，不使用后续 idf.py 命令。
1
2
3
4
5
make menuconfig
make
make flash
make monitor
# 在已按 v2.1 文档配置的独立示例工程中执行
先检查供电与串口，再在独立工程验证。仅使用额定范围内的低压信号，输入不能因为“只是测试”越过芯片限制；烧录成功与外设运行需要分别记录。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 编译失败 | 先检查工具链和目标配置 |
| 烧录成功但启动循环 | 继续查看启动原因和供电 |
| 监视器没有文字 | 核对串口占用与波特率 |
对照 1：编译失败
先检查工具链和目标配置。观察时记录第一条真正的编译错误。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：烧录成功但启动循环
继续查看启动原因和供电。观察时记录复位日志与板端电源。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：监视器没有文字
核对串口占用与波特率。观察时记录实际端口及串口参数。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
不要同时让多个程序占用串口。更换板型后还要重新确认闪存布局和引脚配置，不能仅复用上一块板的菜单选项。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“监视器没有文字”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
