ROS2 节点崩溃后话题残留？生命周期管理与重启动策略

ROS2 节点崩溃后重启，话题还在、数据却不对，这种半残状态比直接挂掉更难查。我的处理思路是让节点死得干净、活得可控。
第一，分清残留是什么。话题本身是无状态的，残留的其实是旧节点的发布者没注销、参数服务器里的旧参数、TF 树里的过期帧。重启后新节点和旧数据混在一起，下游一订阅就拿到过期帧。先 ros2 topic list 和 ros2 node list 对照，僵尸节点先找出来。
第二，用生命周期节点。managed 节点有 configure、activate、deactivate、cleanup 的明确状态，崩溃后按状态机重走一遍，比裸节点直接重跑干净得多。关键节点上生命周期，调试时能单步看状态，线上出问题也能先 deactivate 再排查，不用整机停。
第三，重启动策略要分级。短暂崩溃用 launch 文件的 respawn 立即拉起；反复崩溃要加退避，连续失败三次后停下来告警，别让节点无限重启刷屏日志；涉及硬件的节点重启前先复位驱动，否则新节点一上来就拿到错误硬件状态。
第四，TF 时间戳要把关。旧帧没过期时，新节点一发布就和旧帧打架，表现为定位跳变。重启时清理静态 TF、给动态 TF 设合理超时，下游做时间戳新鲜度检查，过期帧直接丢弃。
第五，崩溃现场要留下来。coredump、rosbag 录崩溃前 10 秒、日志按节点分文件，这三样齐了，复现才有依据。只靠重启掩盖问题，下次还会在同一个地方崩。
你那边 ROS2 节点崩溃，一般是直接 respawn，还是先查僵尸节点和过期 TF？

节点崩溃后话题还在但数据不对，用生命周期状态机重走 configure/activate 比裸 respawn 干净。补充：对照 ros2 node list 与 topic info，清掉僵尸发布者与过期 TF；respawn 要加退避，连续失败三次应停并告警，避免崩溃风暴打满 CPU。参数与 remapping 在 cleanup 阶段显式复位，防止旧参数污染新实例。关键节点的租约与心跳也要进监控，比只看进程是否存在更早发现问题。

补充一个实战中很有效的细节：僵尸发布者的判断不能只看 ros2 node list，还要对照 ros2 topic info -v 看每个发布者的节点名和 QoS，经常能发现同名节点起了两个实例，旧的没死透、新的已经在发，DDS 发现机制下两者会同时存在，下游按 QoS 兼容性随机收到其中一个的数据，表现为时好时坏。

另外建议给关键节点加 bond 心跳：主节点定期检查从节点的 bond 状态，超时直接走生命周期 deactivate 再 cleanup，而不是等它自己崩。配合 systemd 的 Restart=on-failure 和 StartLimitBurst 做兜底，连续失败就停下来告警，现场保留 rosbag 和 coredump 再人工介入。你们线上是倾向于 launch 的 respawn 立即拉起，还是 systemd 托管？两种方式在日志和重启次数统计上差别挺大的。