x/messaging Primer
x/messaging Primer
Section titled “x/messaging Primer”Beta（应用侧服务层）— API 在 minor 版本内保持稳定。下级包（
x/messaging/mq、x/messaging/pubsub、x/messaging/scheduler、x/messaging/webhook）仍为实验性。采用前请查看发布策略和扩展成熟度。
当你已经通过 x/* 家族 确认问题明显属于 messaging 家族，而不是最小 runnable path 时，就打开这一页。
x/messaging 是 queue、pubsub、scheduler 与 webhook 编排在家族层面的 canonical app-facing 入口。
稳定性与采用
Section titled “稳定性与采用”家族级判断先从 x/messaging 开始；直接依赖 x/messaging/mq、x/messaging/pubsub、x/messaging/scheduler
或 x/messaging/webhook 前，再检查下级包成熟度。生产采用前请检查 x/messaging/module.yaml、
发布策略 和 扩展成熟度。
什么时候从这里开始
Section titled “什么时候从这里开始”- 任务是在做消息发送编排
- 改动属于应用侧的 queue、pubsub、scheduler 或 webhook wiring
- 工作需要一个家族级 messaging 入口，而不是更底层的 primitive
什么时候不该从这里开始
Section titled “什么时候不该从这里开始”- 任务真正是 application bootstrap
- 工作是稳定根抽象设计
- 任务已经明确窄化到
x/messaging/mq、x/messaging/pubsub、x/messaging/scheduler或x/messaging/webhook中的低层问题
当前仓库里先读哪些文件
Section titled “当前仓库里先读哪些文件”x/messaging/module.yamlx/messaging/entrypoints.gospecs/extension-taxonomy.yaml
直接打开 subordinate package 前，先使用 family-level alias 和 constructor：
messaging.NewInProcBroker搭配BrokerMessage与BrokerSubscription：进程内 pubsub wiringmessaging.NewWebhookService、messaging.NewWebhookMemStore与VerifyWebhookHMAC：webhook 路径messaging.New：面向应用的 messaging servicemessaging.NewMemReceiptStore：示例和测试里的 receipt 持久化messaging.NewLogSMSProvider、NewLogEmailProvider与 HTTP provider constructor：delivery adapter
更具体的归属例子
Section titled “更具体的归属例子”这些问题应先从 x/messaging 开始 | 只有当任务已经明确窄化后，才继续下钻到这些 sibling |
|---|---|
| 家族级、应用侧的 queue、pubsub、scheduler 与 webhook 编排 | x/messaging/mq 中的 durable queue primitive 与 worker coordination |
| 决定某个服务应该先打开哪个 messaging entrypoint | x/messaging/pubsub 中的 in-process broker primitive |
| 在不重写 canonical app path 的前提下保持编排显式 | x/messaging/scheduler 中的 scheduling primitive |
| 那些仍然比单一协议 primitive 更宽的 messaging-family ownership 问题 | x/messaging/webhook 中的 inbound verification 或 outbound delivery 机制 |
为什么单独写这一页
Section titled “为什么单独写这一页”x/messaging 的价值，在于阻止读者过早跳进某个 sibling 包。家族入口之所以存在，就是为了让消息类工作先从正确的作用域开始，再进一步收窄。