目录标题
- 1. 回调不是“附属品”，它是运行时契约
- 1.1 为什么 vSomeIP 天然需要回调
- 1.2 “接口层回调”到底有多少：一个事实澄清
- 2. 基本三件套：State / Availability / Message 的语义边界与工程写法
- 2.1 `register_state_handler`：你真正关心的是“运行时是否可协作”
- 2.2 `register_availability_handler`：它回答“服务是否可用”，不是“请求是否成功”
- 2.3 `register_message_handler`：消息分发要先“定界”，再“解码”
- 3. 事件订阅链路：Subscription Handler 与 Status Handler 的“互补关系”
- 3.1 两个订阅回调分别解决什么问题
- 3.2 基本回调与扩展回调：一张表把“该配什么”讲透
- 4. 实用场景：回调如何落地为“可维护系统”
- 4.1 最小组合不是“固定 3 个”，而是“按场景配方”
- 4.2 回调写法的三条“硬原则”
- 4.3 常见故障模式：症状—原因—修复对照表
- 结语
SOME/IP 作为面向服务的车载通信协议，既支持请求/响应（RPC），也支持发布/订阅（Event）。vSomeIP 则把这套机制落地为一个运行时与应用协作的框架：应用通过注册回调来接收“状态变化、服务可用性变化、消息、订阅行为”等事件，并在恰当的时机发起 request/offer/subscribe/notify。vSomeIP 官方入门文档也强调了 SOME/IP 的三大部分（on-wire format、protocol、service discovery）以及 RPC 与 P/S 两种交互模式。 ([GitHub][1])
本文聚焦一个在工程里非常关键、却经常被“只记 API 名字”带偏的问题：回调到底该怎么分层、怎么选、怎么写，才能让系统既稳定又好排障？
1. 回调不是“附属品”，它是运行时契约
1.1 为什么 vSomeIP 天然需要回调
从协议层看，SOME/IP 的通信并不是“你调用一次就结束”。服务发现（SD）会不断广播 offer/find；连接与路由状态会变化；订阅可能被确认、拒绝或超时；消息可能乱序抵达或被重传。vSomeIP 将这些异步事实统一抽象为“事件”，再用回调把事件交给应用处理。
这也
