Symfony SyncTransport重复调度：是预期特性还是Bug？

我不确定这是Bug、特性还是我暂时未理解的概念，恳请解惑。

SyncTransport 的 send 方法代码 #

public function send(Envelope $envelope): Envelope
{
    /** @var SentStamp|null $sentStamp */
    $sentStamp = $envelope->last(SentStamp::class);
    $alias = null === $sentStamp ? 'sync' : ($sentStamp->getSenderAlias() ?: $sentStamp->getSenderClass());

    $envelope = $envelope->with(new ReceivedStamp($alias));

    return $this->messageBus->dispatch($envelope);
}

路由配置 #

framework:
  messenger:
    transports:
      sync: "sync://"
    routing: 
      App\TestMessage:   sync

问题现象 #

当为App\TestMessage显式配置路由到sync传输后，消息派发到总线时会经过总线及所有中间件（可能添加Stamp），但在处理器执行前，SyncTransport会再次将消息派发到同一总线，导致中间件重复执行（比如重复添加相同的Stamp）。
若移除路由配置中的App\TestMessage: sync行，该现象消失：无重复Stamp，总线不会被二次调度，仅处理器执行。

解惑：这是预期特性 #

这是Symfony Messenger的预期设计行为，核心逻辑如下：

• 当显式配置路由到某个传输（哪怕是sync传输），Messenger的完整流程是：

  1. 调用messageBus->dispatch()后，消息先经过总线的所有中间件（第一次执行），随后被路由到指定的SyncTransport。
  2. SyncTransport的send()方法会再次调用messageBus->dispatch()——这是sync传输的本质：同步在进程内触发处理器，但它是通过二次调度总线来实现的，所以中间件会被第二次执行。

• 未配置显式路由时，Messenger会启用默认的直接处理器调度逻辑：消息经过总线中间件后，直接匹配对应的处理器执行，不会经过传输层，因此没有二次调度的环节。

如果你的中间件逻辑无法容忍重复执行，有两种解决方案：

• 避免为sync传输配置显式路由，依赖默认的直接调度逻辑；
• 在中间件中通过Stamp做判断（比如检查是否存在ReceivedStamp或自定义标记Stamp），跳过重复执行的逻辑。

内容的提问来源于stack exchange，提问作者dark_982