见过太多这样的启动函数：读参数、打开串口、设一个 ready = true，然后开始干活。平时没问题，直到串口被别的进程占住，ready 一直是 false，上层轮询三分钟后放弃，日志里只留下一句“节点未就绪”。
ready 这个命名没什么错，问题在于它把三件不同的事压成了一个变量：资源有没有打开、配置有没有通过校验、节点有没有真的开始工作。这三件事的失败路径完全不同，恢复方式也不同，但对外只表现为“还没 true”。
生命周期节点做的事就是把这几件事拆开，让节点的阶段变成外部可以查询、可以触发、可以订阅的状态。
bool 标志真正掩盖的是什么
假设启动函数里串口打开失败，它会怎么表现？两种情况：要么函数返回错误但上层没检查，ready 仍然是 true，节点带着空句柄开始跑；要么函数直接 return，ready 保持 false，但没有地方记录“失败在串口这一层”。
第二种情况更常见，也更容易在联调时浪费时间。排查的人要从头猜：是参数没读到，是设备没插，还是权限不对。日志里没有任何信息能缩小范围。
外部依赖会把这个问题放大。控制器只在上游 ready 之后才发命令，那条顺序依赖就藏在一个bool 里。上游先 ready 再崩溃，下游不会收到任何通知；下游先启动，就得写一段轮询；上游重试成功后，之前失败的订阅者也不知道状态变了。
状态是承诺，回调是执行
用生命周期节点，纪律其实只有一条：状态机负责对外承诺，回调负责对内干活，两边必须严格对齐。
on_configure 适合做参数校验、申请资源和一次性准备。它成功，才进 Inactive。很多实现在这里顺手把发布者建好并开始发消息，结果是外部看到 Inactive，却已经在收数据——状态就失去意义了。
on_activate 是真正跨过边界的那一步：允许发布、允许消费、允许定时器驱动。它的失败要认真处理，因为此时可能已经有一半资源进入工作状态。激活打到一半失败，必须能干净地退回起点，不能留下半开的句柄。
on_deactivate 和 on_activate 对称，停掉对外影响但保留已配置的资源。on_cleanup 再进一步，彻底释放，回到 Unconfigured。这两个的差别在于“暂时不干活但随时能上”和“当自己没被配置过”。分不清它们，“重新配置一次”这个很常见的需求就没有正确的落点。
我会怎么验
先看状态和允许的转换：
1 | ros2 lifecycle get /my_node |
list 输出当前状态下允许的目标，这一步能挡住脚本里偷偷调非法转换的问题。实现正确时，Inactive 收到 activate 之外的东西应该被拒绝并保留原状态，而不是进一个没定义的地方。
然后专门测失败路径，别只走顺风流程：
1 | # 设备被占用时 configure，应停在 Unconfigured |
这两条如果都“成功”了，说明转换约束根本没生效，或者回调没有把错误传出去。
和启动编排的关系
生命周期状态最实际的用处，是让启动编排不再靠 sleep 3。编排器逐个把节点推到 Active，每步确认状态而不是猜时间。某个节点长时间停在 Inactive，外部能明确知道是配置失败，而不是笼统地“系统没起来”。
但它解决不了所有事。状态对不代表输出对，节点可以完美地从 Inactive 进到 Active，同时一直在发过期数据。状态也不带时间语义，多节点之间的时钟和新鲜度得单独处理。错误恢复更是另一件事：on_error 之后是自动重试还是等人工介入，得在设计里写清楚，状态机不会替你想。
还有一点容易被忽略：状态查询和转换走的是服务和话题，别放进高频控制回路反复调用。控制线程要的还是内存里的确定状态，生命周期只负责把这个状态的变迁变得可解释。
什么时候别用它
节点不持有需要显式打开和释放的资源，也没有启动顺序，普通初始化就够了，硬加一层状态机只会让调用方多写代码。
真正划算的场景有几个共同点：持有必须显式申请和释放的资源；系统有明确的启动或重启顺序；外部需要在读不到源码的前提下判断节点阶段；或者同一份配置要反复应用和撤销。
这些场景里，生命周期给的不是更强的实时性，而是一份能被查询、被测试、被编排的状态契约。它的价值完全取决于回调有没有和状态一样严格——状态说 Active，节点就真的该在工作。
参考资料
证据边界：这里只讨论状态机结构和接口契约，不涉及任何实时性或恢复能力。状态正确只说明节点声明了阶段，不代表它发出来的数据是新鲜的，也不代表设备已经安全停止。真实硬件上的资源和恢复行为得各自拿证据说话。