[BUG] AMqp延迟队列生成的类型与配置的类型不匹配，设置FANOUT却生成的是Topic #7634
Description
问题描述
在 Hyperf 3.1 的 ProducerDelayedMessageTrait 中，用于延迟队列的交换机类型（x-delayed-type）依赖于宿主类的 $type 成员属性，而不是调用宿主类提供的 getType() 方法。
这导致以下问题：
-
子类重写
getType()方法无效- 即使在 Producer 子类中重写
getType()返回Type::FANOUT或其他类型，trait 内部调用的getTypeString()仍然返回默认$type属性值（通常是Type::DIRECT或Type::TOPIC）。
- 即使在 Producer 子类中重写
-
破坏面向对象封装
- trait 直接访问宿主类的属性，而不是通过公开接口（getter）获取类型，降低了可维护性和可扩展性。
-
扩展性差，容易引发 bug
- 用户按照文档或常规面向对象思路重写方法，结果延迟交换机类型与预期不符。
问题示例
假设我们有一个延迟队列 Producer：
use Hyperf\Amqp\Message\Type;
#[Producer(exchange: 'FanoutDelayDemo')]
class FanoutDelayDemoProducer extends ProducerMessage
{
use ProducerDelayedMessageTrait;
protected array $properties = [];
public function __construct($data)
{
$this->payload = $data;
}
// 用户期望使用 FANOUT 类型
public function getType(): Type
{
return Type::FANOUT;
}
}预期行为：
x-delayed-type应该为'fanout'- 延迟队列消息在到期后可以广播到所有绑定队列
实际行为：
x-delayed-type仍然为'topic'（或父类默认值）- 延迟交换机未按期望类型创建，可能导致消息路由异常。
原因分析
在 ProducerDelayedMessageTrait 中：
->setArguments(new AMQPTable([
'x-delayed-type' => $this->getTypeString()
]));而 getTypeString() 的实现：
public function getTypeString(): string
{
return $this->type instanceof Type ? $this->type->value : $this->type;
}- Trait 依赖
$type属性，而不是调用getType() - 即使子类重写
getType()方法，也不会影响$type的值 - 如果 RabbitMQ 中已经存在同名交换机，旧类型也会被保留
改进建议
- trait 内部使用 getType() 方法，而不是直接访问
$type属性：
public function getTypeString(): string
{
$type = $this->getType(); // 使用方法
return $type instanceof Type ? $type->value : $type;
}- 这样子类重写
getType()方法即可生效 - 保持封装性和可扩展性
- 保持向后兼容（可选）：
$type = property_exists($this, 'type') ? $this->type : $this->getType();- 避免破坏现有用户依赖
$type的写法
- 文档或示例中明确推荐：
- 覆盖
$type属性或者重写getType()方法 - 建议使用枚举
Type类型，而非字符串
总结
- 核心问题：trait 直接访问属性
$type而非调用 getter，导致延迟交换机类型与子类重写方法不一致 - 影响：封装性差、扩展性差、子类配置可能失效
- 改进方向：trait 内部只依赖
getType()方法，并保持对旧$type属性的向后兼容 - 好处：符合面向对象原则，子类可以灵活定义交换机类型，延迟队列行为与预期一致