问题与使用场景

先提交，再投递，最后在消费边界确认或重试。

当你需要确定事件发布相对处理器工作、数据库提交与消费者确认的位置时，使用这张时序图。

这张图适合用于方案评审、故障定位、代码走查与新人导览。它刻意省略与当前问题无关的类和项目，因此应与源码入口和相关专题文档一起使用。

本页范围只覆盖图中命名的职责和关系；未出现的能力需要回到对应模块文档继续确认。

读图路径

第 1 步：从命令开始，经事务行为追踪到处理器。
第 2 步：把状态写入与发件箱追加放在同一数据库事务中理解。
第 3 步：把消息代理投递与消费者确认视为后续可重试阶段。

读图时不要跳过箭头方向、编号和分组标题；它们分别表达依赖或时间方向、执行次序与职责边界。如果图与源码不一致，以当前源码和已接受的架构决策为准，并立即更新生成目录。

图例与表达约定

视觉元素	含义	不能据此推断
珊瑚色焦点	当前图要强调的决策点或主路径	该元素一定更重要或拥有更多权限
蓝色边界	外部系统、协议边缘或显式边界	一定是独立部署服务
灰色连接	依赖、调用、迁移或数据流，具体语义由箭头标签决定	一定同步、同事务或严格一次
分组框	职责、层或生命周期阶段	组织团队或物理机器边界

本图类型为时序。先依据该类型理解布局，再用下文的源码事实校正直觉。

关键关系与设计含义

关系 1

源码事实：处理器在事务行为包围的边界内修改状态。

架构含义：事务行为为聚合变更与处理器触发的发件箱追加提供统一边界。

核对动作：进程崩溃是否可能只提交状态而未记录事件？

关系 2

源码事实：CAP 在数据库事务提交前把集成事件追加到发件箱。

架构含义：CAP 尝试投递前，发件箱记录已经持久化，因此进程故障后仍可恢复投递。

核对动作：消费者能否安全处理同一事件多次？

关系 3

源码事实：消费者确认或重试发生在消息代理投递之后。

架构含义：确认应发生在消费者工作之后，否则重试流程可能确认尚未在本地应用的数据。

核对动作：是否仅在消费者本地工作成功后才发送确认？

设计评审问题

在评审或实现相关变更时，逐项回答下面的问题。无法从代码、测试或 ADR 得到答案时，不应仅凭图示作出结论。

进程崩溃是否可能只提交状态而未记录事件？
消费者能否安全处理同一事件多次？
是否仅在消费者本地工作成功后才发送确认？

如何使用答案

先确定能力或规则的唯一归属方。
再确认依赖、调用或事件方向没有反转所有权。
最后用自动化测试或可重复命令固定结论。

边界与易错点

边界 1

不要在状态提交前直接向消息代理发布。

不要推断：图中出现连接，不等于所有实现都同步调用、共享事务或共享数据所有权。
评审要求：消费者能否安全处理同一事件多次？

边界 2

重试可能再次投递同一事件，因此消费者必须保持幂等。

不要推断：图中出现连接，不等于所有实现都同步调用、共享事务或共享数据所有权。
评审要求：是否仅在消费者本地工作成功后才发送确认？

源码核对与再生成

本图的首要核对入口是 BitzOrcas.Infrastructure.SqlSugar.Outbox.Cap/CapSqlSugarUnitOfWork.cs + BitzOrcas.Infrastructure.EfCore.Outbox.Cap/CapEfCoreUnitOfWork.cs。先检查该入口及其直接引用，再重新生成图表资产和说明页。

# 重新生成中英文 SVG、独立 HTML 与说明页
npm run diagrams

# 检查双语配对、引用、安全属性、可访问性与画布边界
npm run verify:diagrams

# 确认生成结果只包含预期图表与页面变化
git diff -- scripts/diagrams diagram-sources public/diagrams src/content/docs

# 验证站内链接、MDX 结构与专业深度门禁
npm run verify:docs
npm run audit:docs-depth

变更完成清单

图中的职责、顺序、状态或关系与当前源码一致。
新增元素确实有助于回答本页问题，没有把项目清单全部塞进图中。
箭头有明确方向与关系语义，没有暗示不存在的同步或事务保证。
中英文标题、标签、事实与边界保持语义对等。
窄屏、全屏和缩放模式下均可读，没有文字重叠或越界。
相关架构测试、集成测试或验证命令已经执行。
若改变了长期约束，已经同步 ADR 或架构说明。

CAP 发件箱发布时序