ROS 2 回调为什么没有按预期执行：先看执行器和回调组

机器人软件中，订阅消息、定时器和服务响应可能触发不同的回调。开发者看到某个回调迟迟没有执行时，容易只检查网络或消息发送端；而执行器的线程安排、回调分组以及程序内部等待同样值得检查。下面以 ROS 2 的概念和学习记录为例，不对某个现场系统作故障诊断。

先区分回调准备就绪和实际执行

消息到达或定时事件发生，并不等于对应业务代码已经完成。执行器负责处理相关回调；应用的执行顺序与工作负载、执行器及回调组设置等条件有关。记录问题时，应分别标明事件产生、回调开始和回调结束的时间，以及这些时间由什么日志或测量方式得到。

ROS 2 官方执行器文档介绍了执行器与回调组的关系。该页面是滚动开发版本的资料，具体项目应对照实际安装的发行版、客户端库和版本，不把示例中的行为概括为所有版本的时间保证。

互斥回调组限制同一组中的回调并行执行；可重入组允许执行器在适当条件下并发安排回调。允许并发并不代表所有回调一定同时运行，也不自动保证共享数据安全。线程数量、程序耗时和其他资源仍会影响观察结果。

ROS 2 官方rclpy 执行与回调接口资料将执行器和回调组作为控制回调执行的两个组成部分。具体类和用法要以项目使用的客户端库及其发行版文档为准，不能直接将 Python 接口当成 C++ 代码使用。

假设一个学习节点既处理传感器消息，也运行一个定时任务。即便使用多线程执行器，如果相关回调仍在同一个互斥组内，它们也受该组的并发限制。这个例子只解释可能的配置关系，不代表线程设置是任何实际延迟问题的唯一原因。

排查时可以先列出节点中的订阅、定时器、客户端和回调组，再记录每个回调的任务和已知耗时。对照实际代码确认分组，而不是根据启动命令推测。对于未知项保留空白或标记待核实，避免把设计意图误写成运行事实。

如果一个回调等待另一个需要执行器处理的结果，而当前线程或分组又阻止后者运行，就可能出现无法继续的等待。发生与否取决于具体实现和调用方式。团队应检查同步等待、可用线程、回调组和结果处理之间的关系，并参考所用版本的官方建议。

改用并发配置也需要检查共享状态、资源访问和错误处理；不能为了让演示运行就简单删除保护。建议先在不连接真实运动设备的测试环境复现，并让负责软件和安全的人员审查修改，之后再按现场流程验证。

一份有用的记录包括发行版、客户端库、执行器类型、回调组设置、任务输入、运行环境和可重复的观察步骤。说明日志时间所使用的时钟及其来源，保留开始与结束的原始记录；如果没有可靠时间同步，就不要把两台机器的时间差直接当成网络延迟。

测试完成后，记录修改前后的条件和结果，并列出仍未验证的问题。相关背景可参考本站消息与 QoS 语义和机器人技术资讯。本篇是概念梳理，不能代替具体机器人系统的实时性分析或安全验收。