扫码关注
看门狗不是“隔一段时间写一次寄存器”。设计得不好时，系统主任务已经卡死，某个低优先级定时器仍在机械喂狗，设备永远不会复位。面试官通常会借这个问题判断你有没有做过真实可靠性设计。
面试先抓这几个点：
喂狗动作应该与关键任务健康状态绑定，而不是独立定时器无条件执行。
多任务系统可以让各关键任务上报心跳，再由监控任务统一决定是否喂狗。
窗口看门狗不仅检查“太晚”，也能检查“太早”，可以发现异常快速循环。
发生复位后要保留reset cause、关键日志或故障计数，否则设备只会反复重启而没有证据。
面试官真正想听什么
这类题不适合只背一句结论。更稳妥的回答方式是先说明判断条件，再讲工程动作，最后补上验证手段和常见风险。这样更容易让面试官判断你是否真正做过相关工作。
回答时可以按这几个方面组织
单任务裸机
设计重点主流程完整跑通后再喂狗
风险中断里无条件喂狗会掩盖主循环卡死
RTOS多任务
设计重点关键任务分别上报心跳，由监督任务统一喂狗
风险只看某一个任务存活
窗口看门狗
设计重点同时限制最早和最晚喂狗时间
风险初始化和调试阶段时序没处理好
复位追踪
设计重点保存复位原因、启动次数和关键故障上下文
风险现场只看到设备重启过却无法复盘
一个更像工程师的参考回答
我不会把看门狗设计成独立定时器里固定喂。裸机系统里，我会让主业务流程走完一轮并确认关键状态正常后再喂狗；RTOS里会让多个关键任务分别更新健康标志，由监控任务确认都在规定周期内响应后统一喂狗。对于安全性更高的系统，可以使用窗口看门狗，既防止超时也防止程序异常快速循环。看门狗触发复位后，我还会读取并保存reset cause和关键故障信息，否则复位只是恢复服务，没有形成诊断闭环。
面试官可能继续追问
为什么中断里喂狗经常是坏设计？
RTOS里某个任务死锁但系统Tick还在，怎么让看门狗发现？
窗口看门狗相比普通看门狗多解决了什么问题？
看门狗复位后怎样区分软件跑飞和电源掉压？
容易失分的回答
回答只有“开启IWDG，每隔500ms喂一次”。
把看门狗当成万能恢复手段，不考虑复位风暴。
不保存复位原因，现场问题无法定位。
面试前可以这样准备
画出自己项目中关键任务和喂狗关系。
复习芯片的独立看门狗、窗口看门狗和reset cause寄存器。
准备一个“任务卡死但定时器仍正常”的反例。
核心关键词：看门狗、IWDG、窗口看门狗、RTOS任务监控、单片机面试
