集成、自动化与实时能力

先使用平台配置完成常规集成；只有运行机制、协议或中间件超出内建能力时才写扩展代码。

需求	先使用	进入代码扩展的条件
按 Cron 执行业务逻辑	计划任务 + 逻辑流	新任务来源、一次性调度或特殊调度机制
异步生产、消费事件	消息队列 + 逻辑流	新中间件或自定义绑定策略
向在线页面推送状态	WebSocket	新协议、专用网关或自定义连接治理
调用外部 HTTP 服务	外部接口	内建认证和参数模型无法表达

常规配置步骤见 集成与定时自动化。

扩展调度能力

调度负责“何时触发”，业务处理仍放在逻辑流或业务服务中。

1. 使用现有 Scheduler 提交或管理任务。
2. 新增任务来源时实现 ScheduleTaskProvider，不要建立第二套任务注册表。
3. 需要把外部任务定义接入运行时时，通过 ScheduleTaskIntegrator 完成适配。
4. 注册 SPI 或自动配置，并验证应用启动后任务被发现。
5. 使用带唯一标识的测试任务，核对触发时间、输入和最终业务结果。

一次性任务通过程序 API 调度；开发平台的 计划任务 页面只配置 Quartz Cron。

成功标志：任务只注册一次，按预期时区触发，重启后状态符合任务持久化约定，执行失败可在日志和业务结果中定位。

扩展消息能力

消息队列负责投递与解耦，不负责定义完整业务流程。

1. 优先使用 MQBridge 和现有 producer/consumer 抽象。
2. 新增中间件时实现正式适配点，复用绑定模型和运行时加载机制。
3. 消费业务消息时，把处理逻辑放入逻辑流或业务服务。
4. 注册自动配置和必要的元数据。
5. 用唯一消息标识验证生产、入队、消费、失败处理和重复投递行为。

不要在业务模块中直接创建 RabbitMQ 客户端绕过 MQBridge。这会使平台无法统一加载绑定，也会让环境配置和监控出现两条链路。

成功标志：应用配置仍通过消息队列页面管理；消息可以端到端处理；消费失败和重试不会造成无界重复写入。

使用 WebSocket 推送状态

WebSocket 只传递已经产生的业务结果。数据写入、状态迁移和权限判断必须先在业务链路完成。

1. 后端通过现有发送接口选择广播、用户或会话级语义。
2. 前端连接 /websocket/stomp 并订阅与发送端一致的目的地。
3. 保留现有连接鉴权、通道拦截和会话管理链路。
4. 在业务状态变化后发送事件，并在真实页面验证展示更新。
5. 验证未登录、无权限、断线重连和重复消息场景。

只有需要新协议、专用网关或超出现有广播/用户/会话语义的连接治理时，才扩展 WebSocket 底座。

成功标志：有权限的在线用户收到一次可识别事件；无权限用户无法订阅；断线后页面能恢复到服务端真实状态。

组合三条链路

后台任务异步执行并向页面反馈进度时，职责顺序为：

Scheduler 触发 -> LogicFlow / 业务服务生成任务
-> MQ 异步处理 -> 业务状态落库 -> WebSocket 推送结果

每一段都要有独立成功标志。WebSocket 消息不能代替数据库中的最终状态，MQ 消费成功也不能代替业务结果校验。

发布前检查

• 扩展沿用正式接口、SPI 和自动配置，没有直接绑定具体实现。
• 配置项、凭据和中间件地址没有写死在代码中。
• 调度、生产、消费和推送各有一条端到端验证记录。
• 重复触发、重复投递、超时、断线和重启行为已有明确处理。
• 安装方式、兼容平台版本和回滚步骤已记录。

运行巡检见 任务、消息与实时链路维护，其他扩展边界见 平台扩展点总表。