去年秋天一批装在配电箱里的小设备出了个怪毛病白天连着网一切正常到了后半夜总有两三台自己重启串口日志里除了几行看不出来源的乱码什么都没有。换电源、换板子、重新烧固件折腾了整整一周最后发现是那颗3.3V稳压芯片在低温下带不动射频峰值电流。这就是ESP8266的典型性格——它便宜、好用、资料多但只要供电、启动模式、Flash布局、内存管理这几个地方有一处没照顾到它就会用玄学故障的方式让你加班。这篇内容把ESP8266在实际开发中最常撞上的坑按类别捋一遍从供电复位、烧录下载、Wi-Fi连接、崩溃日志、Flash文件系统到GPIO外设每个问题都给出排查顺序和可复现的验证方法。不管你是刚拿到第一块开发板的新手还是已经量产过几批设备的老手下面这些场景大概率都遇到过或者迟早会遇到。1. 供电与复位八成的玄学故障都藏在这里ESP8266出问题我的排查顺序永远是先量电压再看日志最后才怀疑代码。原因很简单这颗芯片在Wi-Fi发射瞬间的电流能冲到300mA以上而平均电流只有几十毫安这种脉冲式的负载特性对电源的要求远高于一般MCU。很多开发板上的USB转串口芯片自带3.3V输出标称能带500mA实际在射频突发时就塌下去了你万用表测出来一直是3.28V看起来很稳示波器一挂就现原形。1.1 供电不足的三种典型表现与实测方法第一种表现是启动即复位串口打印几行启动信息后直接重来反复循环。第二种是连接Wi-Fi时重启日志停在wifi evt: 1或者scandone附近就断了。第三种最坑运行几小时甚至几天才重启一次完全随机让人误以为是软件内存泄漏。判断方法很直接把示波器没有示波器就用手持万用表的最快刷新档虽然看不到尖峰但能看出趋势接在芯片VCC和GND之间探头接地弹簧一定要短否则测到的全是干扰。让设备执行一次Wi-Fi扫描或者发送一个数据包观察电压跌落幅度。健康的情况是峰值跌落不超过200mV如果从3.3V掉到3.0V以下就要从电源上找问题了。常用对策有三条按性价比排序第一换成带足够余量的LDO输入输出压差留足1V输出端并一颗470uF电解电容加一颗100nF陶瓷电容电解电容负责扛住毫秒级的电流脉冲陶瓷电容负责高频去耦两者位置都要尽量靠近芯片VCC引脚走线越短越好第二如果供电是5V直接在前级加一个大电容做能量缓冲第三供电线不要用杜邦线里的细线线径太细带来的压降在峰值电流下非常可观。提示判断是不是供电问题最快的办法是用一台可调直流电源直接给芯片的3.3V引脚供电把电流限制设到500mA如果故障消失基本就可以锁定是原供电电路的问题。1.2 复位引脚、上拉电阻与复位原因的区分ESP8266的EXT_RSTB有的板子标RST是低电平复位正常工作时必须拉高到3.3V。有些模块内部已经有上拉但为了保险外部再并一个10k电阻到3.3V是常见做法。如果这个脚悬空或者上拉电阻虚焊芯片会在电磁干扰下随机复位症状和供电不足极其相似。更有效的判断手段是读取复位原因。Arduino框架下可以用ESP.getResetReason()返回的字符串直接告诉你上一次是什么原因重启的void setup() { Serial.begin(115200); Serial.println(ESP.getResetReason()); Serial.println(ESP.getResetInfo()); }常见的返回值与含义对照如下复位原因字符串含义优先排查方向Power on正常上电无External system外部复位脚被拉低RST引脚、按键、干扰Hardware watchdog硬件看门狗超时长时间阻塞、死循环Software watchdog软件看门狗超时同上注意delay之外的忙等Exception程序异常崩溃空指针、数组越界、栈溢出Deep-Sleep wake深度睡眠唤醒正常现象Software reset代码主动重启ESP.restart()调用位置养成在setup()里打印复位原因的习惯能省掉大量猜测。我曾经遇到一台设备每天重启十几次日志显示全是External system最后查出来是外壳装配时RST引脚的焊盘和金属壳轻微接触温度变化时热胀冷缩导致间歇性短路。1.3 去耦电容与布局的几个关键位置如果是自己画板子有几个位置的电容器千万别省芯片VCC引脚旁边100nF越近越好电源入口处10uF到100uF如果板上有继电器、电机这类感性负载它们的电源要和ESP8266分开走线共地单点连接。射频部分的天线净空区不要铺铜、不要走线、不要放电池这个要求在很多模块的手册里都写了但实际画板时被忽略的比例相当高。还有一个小细节某些模块把Flash和芯片放在同一块小板上Flash的供电和芯片共用如果滤波不好Flash读写时会拉低电压导致取指错误表现就是随机的Exception (2)。这类问题靠改代码永远修不好只能在电源上下功夫。2. 烧录卡在Connecting...一条完整的排查链路如果说供电问题是最隐蔽的那烧录失败就是最常见的。几乎每个用ESP8266的人都经历过串口监视器里一直刷点号、上传进度条走到一半报错、或者干脆提示Failed to connect to ESP8266。这类问题的排查其实有很清晰的顺序关键是不要跳步一次只改一个变量。2.1 接线与电平先确认最基础的三件事第一件事TX和RX必须交叉。模块的TX接 USB转串口的RX模块的RX接转串口的TX这一点新手最容易搞错而且接反了不会烧坏只是没反应所以很难自我发现。第二件事必须共地GND不接或者接触不良通信会时断时续表现就是偶尔能连上偶尔连不上。第三件事供电能力前面说过烧录时射频不工作电流需求不大但如果你的转串口模块3.3V输出只有几十毫安依然可能不够。我的习惯是先用一根短而粗的USB线把模块单独接到电脑上只接TX、RX、GND、3.3V四根线其他外设全部断开确认能正常烧录之后再逐个接回外设。这个最小系统法能排除掉一大半的外部干扰。2.2 启动模式的三个引脚组合ESP8266上电瞬间会采样三个引脚的电平来决定从哪儿启动这是烧录失败最常见的软件层原因。组合关系如下工作模式GPIO0GPIO2GPIO15正常运行从Flash启动高高低串口下载模式低高低SD卡启动高高高也就是说要进入下载模式必须在上电或复位的那一刻GPIO0保持低电平。很多开发板用一个按键加两个三极管做了自动下载电路靠串口的DTR和RTS信号控制但并不是所有板子都做得可靠。如果自动下载老是失败就手动来把GPIO0接到GND按一下复位键松开GPIO0再点上传。这个土办法虽然笨但成功率接近百分之百。另外要提醒一句GPIO15必须为低很多模块内部已经下拉但自己搭电路时如果忘了这个电阻芯片会去尝试SD卡启动同样表现为连不上。2.3 串口驱动、波特率与Flash模式设置驱动层面USB转串口芯片常见的有几款装错驱动或者装了多个版本导致端口号冲突的情况不少见。设备管理器里如果看到带黄色感叹号的未知设备先把旧驱动彻底卸载再装。端口号建议固定成COM10以下某些IDE对高位端口号兼容性一般。波特率方面上传波特率默认115200最稳想提速可以试921600但线材质量差、线太长的时候高波特率反而更容易失败。烧录时串口监视器必须先关掉因为串口是独占资源一边开着监视器一边上传必然报错。Flash设置里最容易出错的是Flash Mode和Flash Size。Flash Mode一般选DIO兼容性最好QIO速度更快但对某些Flash芯片不兼容表现为烧录成功但运行立刻崩溃。Flash Size要和实际芯片一致常见模块是4MB如果误设成1MB程序可能被截断。分区方案Partition Scheme也要和程序大小匹配带OTA的方案会占用更多空间程序一大就会提示空间不足。# 用命令行工具确认Flash信息是个好习惯 esptool.py --port COM3 flash_id这条命令会打印Flash的厂商ID、容量和支持的模式比猜要靠谱得多。如果读出来的容量和你在IDE里设置的不一致那就是问题所在。2.4 一个真实的上传失败复现过程我记录过一次典型的排查过程供参考。现象上传到27%时报Failed to write to target Flash重试三次都是同一个位置失败。第一步换USB线和端口无效排除线材。第二步降低上传波特率到115200失败位置变成31%有变化但没解决说明和时序有关。第三步用flash_id读芯片信息容量显示4MB模式支持DIO和QIO正常。第四步怀疑供电外接稳压电源后依然失败。第五步换一块同型号模块成功。把问题模块单独拿出来用橡皮擦了一遍排针重新焊接了Flash芯片的八个引脚再试成功。结论是Flash芯片有个引脚虚焊高温或者轻微形变时接触不良。这个案例的启示是当软件层的参数都排查完还是失败就要怀疑硬件连接尤其是那些看起来焊上了但实际虚焊的引脚。用手按压Flash芯片或者用热风枪补焊往往能验证这个猜测。3. Wi-Fi连接失败与频繁掉线拆掉信号满格的假象手机显示Wi-Fi信号满格设备却连不上这是ESP8266用户抱怨最多的问题之一。原因在于手机和ESP8266的射频能力完全不在一个量级手机能收到的弱信号ESP8266未必能解调出来而且ESP8266只支持2.4GHz频段对某些路由器设置天然不兼容。3.1 频段、信道与带宽的兼容性ESP8266只支持2.4GHz这一点必须刻在脑子里。如果你的路由器开了5GHz同名SSID设备有时能连上有时连不上那大概率是被分配到了5GHz频段或者路由器在做频段引导。解决办法是在路由器上把2.4G和5G的SSID分开命名让设备只认2.4G那个。信道方面2.4GHz有1到13信道不同区域允许的信道不一样有些设备固件只扫描到11信道。如果路由器设置成自动选择信道而恰好选到了12或13部分模组就会扫描不到。这种情况在进口路由器和某些企业级AP上出现过手动把路由器信道固定到1、6、11这三个互不重叠的信道是最省心的做法。带宽设置也值得一提。路由器如果强制40MHz带宽在拥挤的环境下反而容易受干扰掉线改成20MHz通常更稳定代价是理论速率下降但对ESP8266这种应用影响不大。3.2 连上了却上不了网DHCP与DNS的排查有一类问题很迷惑串口打印WL_CONNECTEDWiFi.localIP()也拿到了地址但HTTP请求永远超时。这时候要分两步查。第一步查网关。用WiFi.gatewayIP()打印网关地址然后在同一网络下的电脑上ping这个网关确认网络本身是通的。第二步查DNS。很多固件里直接写client.connect(api.example.com, 80)域名解析失败就会一直卡住而错误码又不会明显提示。稳妥的做法是先用IP地址测试通说明是DNS问题再用WiFi.hostByName()手动解析域名并打印结果。IPAddress resolved; if (WiFi.hostByName(your-server.com, resolved)) { Serial.print(DNS OK: ); Serial.println(resolved); } else { Serial.println(DNS failed); }如果手动解析也失败检查路由器下发的DNS地址是否正确或者直接在代码里指定一个公共DNS。还有一个容易忽略的点某些企业网络需要网页认证设备端拿不到认证页面自然上不了网这种环境只能换网络测试。3.3 掉线重连与睡眠模式的副作用设备能连上但隔几分钟掉一次重连后又正常这种周期性的掉线往往和睡眠模式有关。ESP8266默认开启了modem sleep在空闲时会关闭射频以省电某些路由器对长时间没有数据交互的客户端会主动踢掉。解决办法是关掉睡眠WiFi.setSleepMode(WIFI_NONE_SLEEP); WiFi.setAutoReconnect(true); WiFi.persistent(false);persistent(false)这一行值得单独说。默认情况下ESP8266会把Wi-Fi配置写进Flash如果代码里频繁调用连接函数Flash会被反复擦写几百次之后那块扇区就可能损坏表现为配置存不住、启动异常。把它设为false之后配置只保存在内存里重启后重新连接虽然慢一点但Flash寿命有保障。重连逻辑方面不要依赖库的自动重连做全部工作。稳妥的写法是在主循环里检测状态掉线超过一定时间就主动WiFi.disconnect()再WiFi.begin()同时加一个退避机制重试间隔从1秒逐步拉长到30秒避免在网络确实不可用时疯狂重连把CPU占满。3.4 天线净空与结构件的隐性影响这一条经常被硬件工程师忽略。模块的板载天线对周围金属极其敏感如果设备装进金属外壳或者天线正对着电池、螺丝、走线信号会衰减十几dB表现就是离路由器三米就掉线。做产品时天线区域下方和前方至少留出5到10毫米的净空外壳如果是金属的要么开窗要么用外置天线版本。还要注意人体影响。手持设备和放在桌面上的信号表现完全不同测试时要模拟真实使用姿态。我曾经有个项目样机在实验室一直很稳装到现场立杆上就开始随机掉线最后发现是安装支架的金属抱箍正好压在天线正下方。4. 运行中崩溃与复位循环读懂串口里的异常日志代码跑着跑着突然重启串口吐出一大段十六进制数字这是ESP8266开发中最让人头大的场景。很多人看到这段日志直接懵掉其实它包含的信息非常多读懂之后定位问题会快很多。4.1 Exception后面的数字和堆栈怎么看崩溃日志的典型形态是这样的Exception (28): epc10x4020a1b4 epc20x00000000 epc30x00000000 excvaddr0x00000000 depc0x00000000 stack ctx: cont sp: 0x3ffef1e0 end: 0x3ffef3e0 offset: 0x01a0 3ffef380: 00000000 3ffe8f4c 3ffef3d0 40202b1c ... stackException (28)里的数字是异常类型最常见的几个含义如下异常编号含义常见原因0非法指令函数指针错乱、Flash内容损坏2取指错误Flash读取失败、代码区被覆盖3读写错误访问了非法地址9软件看门狗长时间阻塞28内存访问错误空指针、数组越界、野指针29内存写入错误向只读区或非法地址写入其中28和29占了我遇到的大多数。excvaddr这个字段特别关键它记录了出错时访问的地址。如果excvaddr0x00000000基本可以断定是空指针解引用如果是个奇怪的地址比如0x3ffexxxx可能是数组越界如果是0x40000000附近的地址可能是函数指针被破坏。堆栈部分是一串地址需要配合编译生成的.elf文件反查。Arduino IDE可以把编译输出打开找到生成的elf文件然后用工具把地址翻译成函数名和行号。手动做这件事很麻烦社区有现成的异常解码工具把整段日志粘进去就能自动解析省事很多。我在项目里养成的习惯是每次发布固件都保留对应的elf文件出问题时才能对得上号。4.2 看门狗复位与阻塞式代码看门狗是ESP8266的自我保护机制程序卡死超过一定时间就会强制重启。硬件看门狗默认大约几秒软件看门狗可以配置。触发看门狗的最常见原因是长时间阻塞while循环等待某个标志位、delay()时间过长、在中断里做了耗时操作。特别要提醒的是delay()。在Arduino框架下delay()内部会让出CPU并喂狗所以短时间的delay()不会触发看门狗但如果在delay()之外的忙等循环里不喂狗几秒钟就会重启。正确做法是把长任务拆成状态机每次循环只做一小步主循环自然就喂狗了。// 不推荐忙等会触发看门狗 while (!sensorReady()) { } // 推荐非阻塞轮询 static unsigned long lastCheck 0; if (millis() - lastCheck 100) { lastCheck millis(); if (!sensorReady()) return; // 继续后续逻辑 }如果确实有无法拆分的长任务可以在循环里手动调用ESP.wdtFeed()或者yield()但这只是权宜之计根本方案还是重构代码。4.3 堆内存碎片与String的使用边界ESP8266的可用堆内存大约40KB左右听起来不少但Wi-Fi协议栈本身要占掉一大块实际留给应用的只有20多KB。在这种资源条件下大量使用String拼接是危险动作。String每次拼接都可能重新分配内存反复分配释放之后堆就碎掉了最终某次分配失败导致空指针崩溃日志显示Exception (28)但你怎么查代码都找不到明显的越界。判断堆是否健康可以在主循环里定期打印剩余堆和最大可分配块Serial.print(free heap: ); Serial.println(ESP.getFreeHeap()); Serial.print(max block: ); Serial.println(ESP.getMaxFreeBlockSize());如果getFreeHeap()还有十几KB但getMaxFreeBlockSize()只有一两KB说明碎片严重。解决办法是把String换成固定长度的char数组用snprintf拼接JSON解析用流式解析库不要一次性构造大字符串对象尽量在栈上分配避免频繁new和delete。4.4 固件版本与第三方库的兼容性还有一种崩溃是升级之后才出现的之前一直好好的。这种情况优先怀疑库版本。Arduino的ESP8266核心库迭代很快不同版本之间的API行为、内存布局、中断处理都可能有变化某个库在新版本上编译通过但运行崩溃是很常见的。我的做法是把项目的库版本固定下来在工程里记录每个库的版本号和来源升级时一次只升一个跑够24小时稳定再升下一个。核心库的版本也要固定不要用最新版就完事尤其是量产项目能跑通的版本就是最好的版本。5. Flash、文件系统与OTA那些写完就坏的坑ESP8266的程序和文件都放在外挂的SPI Flash里Flash的容量、分区、擦写寿命直接决定了项目的稳定性。这一块出的问题往往有延迟性写的时候没事跑一段时间才暴露。5.1 分区表与Flash容量不匹配官方核心库提供了几种预设的分区方案从1MB到16MB不等。选错方案的表现有两种程序编译时报text section exceeds available space或者烧录成功但运行时反复重启日志显示Exception (2)取指错误。自己算一下就很清楚一个带Wi-Fi和HTTPS的程序代码段轻松超过500KB如果选了1MB Flash且带OTA的分区方案每个程序区只有不到500KB根本放不下。建议在项目初期就确定Flash容量至少选4MB分区方案选带OTA且给文件系统留出空间的。如果需要自定义分区可以用工具生成分区表CSV然后在编译选项中指定。分区表里几个关键字段是名称、类型、子类型、偏移和大小偏移必须按4KB对齐且不能重叠改完一定要用工具校验一遍否则烧录后可能出现程序区和文件系统区互相覆盖表现为文件莫名损坏。5.2 SPIFFS与LittleFS的掉电损坏要在Flash里存配置文件或者网页资源就得用文件系统。早期大家用SPIFFS后来逐渐转向LittleFS主要原因是SPIFFS在掉电时容易损坏整个文件系统而LittleFS有日志和磨损均衡机制掉电后恢复能力更强。不管用哪个有几个操作习惯必须养成写入文件时先写临时文件写完再重命名避免写一半掉电导致原文件也损坏配置文件加上校验和读取时校验失败就回退到默认值不要在每次循环里写文件把写操作合并、降低频率Flash的擦写寿命一般标称10万次看着多但每秒写一次的话一天就写掉八万多次。// 配置写入的稳妥做法 void saveConfig(const Config cfg) { File f LittleFS.open(/cfg.tmp, w); if (!f) return; f.write((uint8_t*)cfg, sizeof(cfg)); f.close(); LittleFS.remove(/cfg.bak); LittleFS.rename(/cfg.dat, /cfg.bak); LittleFS.rename(/cfg.tmp, /cfg.dat); }这段逻辑虽然简单但能保证任何时刻掉电至少有一个完整可用的配置备份。5.3 OTA升级失败与回滚设计OTA是ESP8266很实用的功能但失败率比有线烧录高得多。常见失败原因有三个升级过程中断电、网络中断导致下载不完整、新固件本身有问题导致启动崩溃。前两个可以靠校验解决。下载完成后先校验MD5或者文件大小确认无误再调用Update.end(true)提交中途失败就调用Update.end(false)放弃原有固件不受影响。第三个问题最麻烦新固件启动就崩溃设备变砖只能拆下来有线烧录。解决办法是在新固件启动后先做自检比如连续稳定运行30秒、Wi-Fi能连上、关键外设能读到数据全部通过才标记升级成功否则主动回滚到上一个分区。// 简化的自检与回滚思路 void checkBootOK() { if (readBootFlag() BOOT_TRIAL) { if (!selfTest()) { ESP.restart(); // 触发回滚 } writeBootFlag(BOOT_OK); } }这套机制需要在分区表里预留两个程序区并且引导程序支持回滚。核心库的OTA机制本身带有一定的回滚能力但具体行为要看版本建议在自己的代码里再加一层应用级自检双保险。6. GPIO与外设引脚复用表之外的经验引脚不够用是ESP8266项目的常态但在想办法挤出引脚之前得先知道哪些引脚能碰、哪些碰了会出事。手册上的引脚表只告诉你功能很多使用限制是在实际调试中才体会到的。6.1 那几个不能随便用的引脚GPIO0、GPIO2、GPIO15这三个引脚在启动时被采样决定了启动模式所以它们上面接的外设必须保证上电瞬间不会把电平拉错。比如GPIO0接了一个按键到地上电时如果按键被按住芯片就进下载模式了表现为程序不运行。正确做法是按键接在别的引脚上或者用三极管隔离。GPIO16比较特殊它属于另一个电源域支持深度睡眠唤醒但内部上拉和中断能力和别的引脚不同做输入时只能配置INPUT_PULLDOWN_16没有内部上拉。用它接按键的话外部必须加上拉电阻。GPIO6到GPIO11连接着SPI Flash绝对不能用作普通IO用了必然崩溃。GPIO9和GPIO10在某些模块上引出但同样有大坑非必要不要碰。A0是唯一的模拟输入量程0到1.0V大部分开发板加了分压电阻标称能测0到3.3V但分压比不一定精确做精度要求高的采集时要自己校准。而且A0只有一个多路模拟量要么用外部多路复用器要么换带多路ADC的方案。6.2 I2C上拉、PWM频率与中断时序I2C在ESP8266上可以用任意GPIO模拟但默认的SDA是GPIO4、SCL是GPIO5。必须注意的是外部上拉电阻不能省内部上拉很弱几十厘米的排线加上几个从设备信号边沿会变得很缓表现为偶尔读到0xFF或者总线锁死。一般用4.7k到10k的上拉设备多、线长的时候取小值。PWM方面默认频率是1kHz、范围1023驱动LED够用但驱动舵机或者调光就需要改。改频率用analogWriteFreq()改分辨率用analogWriteRange()两个要配合着调频率高的时候范围要相应减小否则占空比精度不够。还有一个限制是PWM通道数量有限同时驱动多路时要注意分配。中断处理里不要做耗时操作不要调用delay()不要用Serial.print()。中断里只置一个标志位具体处理放到主循环里做这是嵌入式开发的通识但在ESP8266上尤其重要因为Wi-Fi协议栈对时序很敏感中断里耽误太久会导致连接异常。6.3 传感器读数漂移的排查思路接上传感器读数不稳先别怀疑传感器。按这个顺序查第一供电是否干净传感器和ESP8266共用一路电源时射频工作的瞬间电压波动会被传感器放大成读数跳变给传感器单独加一颗100nF加10uF的组合电容往往立竿见影第二线材长度I2C超过半米就要考虑降低速率或者用屏蔽线第三上拉电阻是否合适第四读取时序是否符合传感器手册要求有些传感器两次读取之间需要足够的转换时间读太快会拿到上一次的旧值。单总线器件比如常见的温湿度传感器对时序要求严格到微秒级ESP8266在开启Wi-Fi时偶尔会被协议栈打断导致时序错乱读出85或者0这样的错误值。解决办法是读取时短暂关闭中断或者连续读三次取中间值做滤波。7. 让设备连续跑上几个月我自己的稳定性检查清单前面讲的都是具体故障最后分享一套我在项目里固定执行的检查流程。每次固件准备发布前按这个清单过一遍能拦下大部分会在现场暴露的问题。检查项具体做法通过标准复位原因每次启动打印getResetReason连续72小时无非预期重启堆内存每小时记录空闲堆和最大块无持续下降趋势Wi-Fi重连手动断开路由器再恢复60秒内自动重连成功掉电恢复随机时刻断电20次每次都能正常启动并加载配置长时间计时用millis()做跨天测试无溢出导致的逻辑错误Flash写入统计单位时间写入次数每小时不超过10次关于millis()溢出这个坑很多人在设备跑满49天之后才会遇到因为millis()返回的是无符号32位大约49.7天回绕一次。避免的方法很简单所有时间比较都用减法// 错误写法溢出后会判断失误 if (millis() lastTime 1000) { } // 正确写法无符号减法自动处理回绕 if (millis() - lastTime 1000) { }另外设备在现场的环境适应性也要提前考虑。温度对晶振频率有影响低温下Wi-Fi连接成功率会下降湿度大会导致PCB表面漏电复位引脚被轻微拉低电源电压波动范围要按实际电网情况留足余量。这些问题在实验室里永远复现不出来只能在设计阶段就把余量做足。还有一个我踩过的坑某批设备在雷雨季节集中返修查下来是电源入口没有加 TVS 管感应雷通过电源线打坏了稳压芯片。后来在入口加了压敏电阻和TVS问题再没出现过。这类防护器件的成本只有几毛钱但能省掉整批返修的麻烦。最后再提一句调试习惯。给每台设备留一个串口日志输出口日志里带上时间戳、复位原因、Wi-Fi状态、堆内存这几个关键字段出问题时让现场人员把日志导出来比远程猜测高效得多。我自己就是因为坚持打这几行日志才在几次看似无解的现场故障里找到了线索其中一次就是靠复位原因的统计分布定位到了某一批次的电源芯片存在批次性问题。
按送审节点给了判断)
