必须在messagehandler函数内用defer recover()捕获panic，否则goroutine退出导致后续消息静默丢失；recover后应记录topic、payload长度等上下文并自然退出，不可阻塞或共享状态。
MQTT handler里panic会导致整个订阅流中断
MQTT客户端收到消息后，会调用你传入的MessageHandler函数。如果这个函数内部panic（比如解码JSON失败、空指针访问、除零），而你没做任何捕获，那么该goroutine直接退出，后续同主题的消息将不再被处理——不是broker断连，也不是client掉线，是handler本身“死”了，但client还活着，只是静默丢弃新消息。
常见现象：订阅后前几条消息正常打印，某次收到非法payload后，日志停了，但client.IsConnected()仍返回true，连接状态看似完好。
- 必须在
MessageHandler函数体开头就注册defer func() { recover() }()，不能只在上层包装一层再传给Subscribe() - 别把recover写在handler外部——handler是独立goroutine，只有它自己能recover自己
- recover后不要return或继续处理当前消息，应记录错误并让handler函数自然结束，避免状态污染
recover后怎么安全地记录错误和转发消息
单纯recover()不报错，程序继续跑，但你可能漏掉关键上下文：哪条topic、哪个qos、payload多长、broker时间戳？这些对排查“为什么这条消息会panic”至关重要。
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- 在
defer中调用debug.Stack()获取完整堆栈，但生产环境要关掉，改用fmt.Sprintf("%v", r)加msg.Topic()和len(msg.Payload()) - 不要在handler里直接写数据库或发HTTP请求——这些操作可能再次panic，且阻塞MQTT事件循环；应把
msg推到一个带缓冲的chan MQTT.Message，由单独goroutine消费 - 若需重试，别在handler里
client.Publish()——此时client可能正忙于收消息，应走异步队列+指数退避
为什么用gin.Recovery()或全局main defer救不了MQTT handler
很多人习惯在HTTP服务里用gin.Recovery()兜住所有请求panic，于是想当然地在main()加defer func() { recover() }()来“保MQTT”。这完全无效。
-
recover()只对**当前goroutine**生效；Subscribe()注册的handler是MQTT库内部启动的goroutine，和main()完全隔离 - 即使你在
main()里recover，也只会捕获main()自己的panic，对MQTT消息处理线程毫无影响 - paho.mqtt.golang等库从不帮你wrap handler——它只负责调用你传进去的函数，panic冒泡到哪，就停在哪
handler里recover后还能继续收下一条消息吗
可以，但前提是recover之后handler函数干净退出，不残留panic状态、不关闭channel、不重复释放资源。
- 确保handler内所有
defer都只清理本消息相关资源（如临时buffer、解码器实例），不要碰client或全局连接 - 避免在handler里调用
client.Disconnect()或client.Unsubscribe()——这些操作应由上层控制逻辑统一调度，否则可能造成连接震荡 - 最易忽略的一点：如果handler里用了闭包捕获了外部变量（比如循环中的
topic），recover后该变量状态可能已损坏，下次执行仍panic；务必用局部副本：func(topic string) { return func(...) { ... } }(topic)
recover()，而是让每次panic后，handler能像没发生过一样继续工作——这要求你把每条消息当作原子单元处理，不共享状态、不依赖前序结果、不持有跨消息资源。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
