有很大可能和供电相关，而且你看到的TG1WDT_SYS_RST/RTC_SW_SYS_RST这类复位原因，常见就是“电源不稳 → CPU/任务跑飞/卡死 → 看门狗触发”或“电源波动导致某段代码主动调用 esp_restart()（例如检测到异常）”。在供电稳定后现象消失，这个相关性非常强。
下面给你一套从机理 → 证据 → 规避方案的实战排查/改进清单（ESP32-C3 适用）。
1) 这两种复位通常意味着什么
TG1WDT_SYS_RST：Timer Group 1 的看门狗触发复位
常见原因：高负载时某个任务长期得不到调度、临界区太久、禁中断太久、SPI Flash 访问异常卡住、Wi-Fi/BLE 驱动卡住等。供电抖动会放大这些问题（尤其是 Flash/射频瞬态电流导致电压下陷）。RTC_SW_SYS_RST：软件触发系统复位
典型来源：代码调用esp_restart()/abort()导致重启，或者某些组件检测到异常后触发重启。供电异常也可能触发异常路径（例如 NVS/Flash 读写失败、Wi-Fi 启动失败反复重试最后重启）。
2) “临界电压/电流”下为什么会表现成 WDT/软件复位，而不是 Brownout？
因为电源问题不一定是“持续低压”，更常见是瞬态压降/纹波/尖峰：
Wi-Fi 发射瞬间、CPU 提频、Flash 读写瞬间，电流脉冲很大
电源路径阻抗（线太长、DC/DC 响应慢、LDO 余量不足、走线太细、地弹跳）→ 造成VDD 瞬间下陷
下陷短到没触发 brownout，但足以让 Flash/QSPI 或总线出现错误、任务卡住、驱动异常，最终WDT 或软件自恢复重启
所以“换稳定供电就好了”完全符合这个机理。
3) 你该怎么快速确认是不是供电
A. 直接抓波形（最有效）
用示波器在模组 3V3 引脚附近测：
触发条件：跌落到 3.0V/2.9V 附近（你们系统门限不同）
重点看：Wi-Fi启动、连接、发包时是否有明显下陷/振铃
注意：探头接地要短（弹簧地），否则你会看到假的振铃。
B. 软件侧打印更细的复位信息
打印
esp_reset_reason()打印启动时的
rtc_get_reset_reason()（如果你们有）开启 WDT 触发时的 backtrace/任务名（如果可用）
C. 人为制造负载验证
提高 Wi-Fi 发包功率/频繁扫描
提高 CPU 频率
连续 Flash 读写
如果这些动作更容易复位，基本锁定供电/瞬态。
4) 规避方案（工程上最常用、最有效）
方案 1：把“电源瞬态能力”做足（优先级最高）
就近去耦/储能（贴在模组 3V3 pin 附近）
0.1µF + 1µF（高频去耦）
再加10µF ~ 47µF（低频/瞬态储能）
如果你现在只有 10µF，建议提升到 22µF/47µF 试试（低 ESR）
电源芯片选型/余量
LDO：确保在峰值电流下仍有足够压差；注意温升会降能力
DC/DC：看瞬态响应（load step response），必要时加输出电容/补偿
降低电源路径阻抗
3V3 走线加宽、缩短
地回路完整、避免细长地线导致地弹跳
如果是线束供电，线束压降非常常见（尤其 500mA 级脉冲）
方案 2：开启/校准 Brownout，让复位更“可控”
如果你现在 brownout 被关闭或门限太低，建议开启并设置合适门限
这样电压下陷时会直接 brownout reset，而不是跑飞卡死触发 WDT，现象更可诊断，也更安全。
（门限要结合你们 3V3 最低工作电压与系统余量来定，别设太高导致误复位。）
方案 3：降低峰值电流 & 负载突变
Wi-Fi 发射功率适当降低（
esp_wifi_set_max_tx_power）避免“Wi-Fi 启动同时大量外设上电/LED 全亮/电机启动”
把耗电动作分散：上电后延迟启动 Wi-Fi，或分阶段初始化
方案 4：软件侧让 WDT 更不容易误杀（但别当根因解决）
检查是否有长时间关中断/长临界区
大循环里加
vTaskDelay(1)或喂狗点避免在高负载期间同步阻塞 Flash/IO 太久
如果有 PSRAM/Flash 操作，确保在电源抖动时不会进入死循环重试
但如果根因是供电，软件只能“缓解”，不能根治。
5) 建议你先做的 3 个动作（最快出结果）
在模组 3V3 就近加 47µF + 1µF + 0.1µF（低 ESR）
示波器抓一次 Wi-Fi 连接/发包时 3V3 波形
降低 Wi-Fi Tx Power + 上电延迟启动 Wi-Fi（例如延迟 1~2 秒）做对比实验
只要这三步做完，基本就能判断：是不是瞬态压降导致。
)