嵌入式产品稳定性：看门狗、掉电保护、日志和异常恢复

一、嵌入式稳定性为什么难

嵌入式设备经常长期无人值守运行，环境比普通服务器复杂：

• 可能突然断电。
• 可能网络不稳定。
• 可能温度变化大。
• 可能存储寿命有限。
• 可能没有人工现场维护。

所以嵌入式开发必须考虑异常恢复。

二、看门狗

看门狗用于检测系统是否卡死。

基本逻辑：

程序定期喂狗
如果长时间不喂狗
硬件或内核触发重启

Linux 下常见设备：

/dev/watchdog

使用建议：

• 主业务正常才喂狗。
• 不要单独开一个无条件喂狗线程。
• 喂狗周期要留足余量。
• 重启后记录原因。

错误用法：

while true:
    feed_watchdog()
    sleep(1)

这样业务卡死了也会继续喂狗，看门狗失去意义。

三、掉电保护

突然断电可能导致：

• 文件写一半。
• 数据库损坏。
• 配置文件为空。
• Flash 写坏。

建议：

• 配置文件写临时文件后 rename。
• 关键数据使用事务。
• 避免频繁写 Flash。
• 重要状态做双备份。
• 使用只读根文件系统加数据分区。

安全写配置：

write app.conf.tmp
fsync
rename app.conf.tmp -> app.conf

rename 在同一文件系统内通常是原子操作。

四、日志策略

嵌入式存储有限，日志不能无限写。

建议：

• 日志分级。
• 限制单个日志文件大小。
• 保留最近 N 个文件。
• 关键异常单独记录。
• 避免高频刷写 Flash。

常见日志目录：

/var/log/my_app/
/data/logs/

如果是只读 rootfs，可以把日志放到独立数据分区。

五、异常恢复

程序应该能处理：

• 网络断开后重连。
• 外设异常后重新初始化。
• 配置错误时给出明确日志。
• 子模块失败不拖垮整个系统。
• 进程崩溃后由 systemd 拉起。

恢复策略要区分：

• 可恢复错误。
• 需要重启进程。
• 需要重启系统。
• 需要进入安全模式。

六、安全模式

如果设备连续启动失败，可以进入安全模式。

示例策略：

记录启动失败次数
连续失败 3 次
不启动业务应用
只启动网络和诊断服务
等待远程修复

这比设备无限重启更可控。

七、健康检查

应用可以周期性输出健康状态：

network=ok
sensor=ok
disk=ok
memory=ok
last_upload=2026-06-21 13:00:00

健康检查可以用于：

• 是否喂狗。
• 是否上报平台。
• 是否触发自恢复。
• 是否进入安全模式。

八、存储寿命

Flash 有擦写寿命。不要把高频日志、状态、计数器不断写入同一位置。

优化方式：

• 降低写频率。
• 批量写。
• 环形日志。
• 使用数据库事务。
• 使用磨损均衡文件系统。
• 把临时数据放内存文件系统。

九、总结

嵌入式稳定性不是最后补一个看门狗就行，而是贯穿设计：

异常检测 -> 日志记录 -> 自动恢复 -> 防止数据损坏 -> 可远程诊断

产品越接近量产，越要重视这些非功能需求。