ROS2 动作 Action 长时间无反馈？从 goal 取消到超时处理

ROS2 Action 用起来比 Service 方便，但长时间无反馈时排查起来很绕，因为它涉及客户端、服务端、执行器三方状态。分享一套定位思路。
首先区分是没收到反馈，还是反馈丢了。用 ros2 topic echo 看 /feedback 话题有没有数据，再用 ros2 action info 看服务端状态。如果话题有数据但客户端没收到，多半是 QoS 不匹配或客户端回调被阻塞；如果话题本身就没数据，问题在服务端执行逻辑。
其次检查 goal 状态机。Action 的 goal 有 accepted、executing、succeeded、canceled、aborted 几种状态，长时间卡在 executing 但无反馈，常见原因是执行器线程被阻塞，比如在回调里做了耗时操作，或者 executor 单线程被长任务占住。改成多线程 executor 或把耗时操作放单独线程，往往就通了。
第三是取消与超时。客户端取消 goal 后，服务端不一定立刻响应，要确认服务端实现了 cancel 回调；没有超时机制的 Action 客户端会一直等，建议业务层自己加超时：超时后先 cancel，cancel 无响应再考虑重启节点，别直接 kill 导致状态残留。
第四是日志分层。Action 服务端要打 goal_id、状态变迁、执行耗时三类日志，否则事后复现只能靠猜。
你们用 Action 时有没有遇到过 goal 卡住的情况？一般怎么给长时间任务加超时保护？

Action 无反馈先分「话题有数」还是「执行器卡住」，这个分层很实用。补充：单线程 executor 里若在 execute 回调做阻塞 IO，反馈与 cancel 都会一起饿死；把耗时放到独立线程并用原子标志响应 cancel，比单纯加长超时更安全。QoS 上反馈与状态话题要与客户端期望一致，否则 echo 看得到、应用回调永远不进。验收时建议刻意打一次 cancel 与 abort，确认资源释放和上层状态机可恢复。

独立线程加原子标志这点很关键，我们的做法再细化一步：执行线程每轮循环都要检查取消标志，不能只在任务开头和结尾查一次，否则长耗时循环里取消还是要等一整轮。反馈也不要等执行完才发，执行线程按固定周期把进度写进共享状态，由单独的反馈线程或定时器发布，这样反馈频率和执行进度解耦，执行卡住时反馈停滞本身就是可观测的故障信号。超时建议分两级：软超时先发取消并等待一个短的回收窗口，窗口内未回正再走硬超时，强制停机并把目标置为中止，同时释放电机使能和夹持资源，避免上层以为任务还在跑又发了新目标。验收时我们会刻意在执行中途打取消、在反馈话题上制造丢包，确认状态机、资源释放和上层重试三者都回到可恢复状态才算通过。