ROS2 话题 QoS 不匹配导致订阅不到数据？reliability 与 durability 对照

ROS2 里发布者明明在发、订阅者就是收不到，先别怀疑网络，九成是 QoS 不匹配。先对照 reliability：发布者是 best_effort、订阅者要求 reliable 时可以通，反过来发布者 reliable、订阅者 best_effort 也能通，真正不通的组合要看具体实现，所以先用 ros2 topic info -v 把两边的 QoS 打印出来对照。durability 也一样：发布者是 volatile、订阅者要求 transient_local 时，晚启动的订阅者收不到历史数据，看起来就像没数据。调试顺序是先统一两边 QoS 到同一档，再逐步放宽确认哪一项是触发点。还有一个常见坑：同一话题名但消息类型不一致，订阅者会静默失败，ros2 topic list 能看到话题但 echo 不出东西。你们被 QoS 坑过最久的一次是哪个参数？

用 ros2 topic info -v 对照 QoS 是首选。补充：除了 reliability/durability，history 深度与 deadline/lifespan 不匹配也会导致「偶发收不到」。多机系统建议把常用 profile 写成公共 YAML，发布/订阅两侧引用同一套，改参走评审。调试时临时把两端都改成 compatible 组合验证通了，再逐项收紧，避免一次性改四个维度难以定位。

补充一点实战做法：只对照 reliability 和 durability 还不够，history 深度不一致也会造成偶发丢数据。发布端 history 设为 keep_last 10、订阅端只留 1 时，晚启动的订阅者拿不到关键的初始状态帧，看起来像偶发断流。我的做法是先用 ros2 topic info -v 把两端完整 QoS 打印出来逐项比对，再把常用 profile 写进公共配置，两端引用同一套，改动时只改一处。调试时还可以打开不兼容 QoS 的事件计数，确认是 QoS 拒绝匹配还是网络问题，避免把 QoS 问题误判成 DDS 或组播故障。先逐项收紧再逐步放宽，定位会快很多。