正确做法是调用channel.queuebind添加绑定、channel.queueunbind移除绑定；二者均需确保交换机和队列已预先声明，且仅按queue/exchange/routingkey三元组匹配，不支持args解绑，也无api可查询当前绑定关系。
用 ExchangeBind 和 ExchangeUnbind 动态操作路由绑定
Go 客户端（streadway/amqp）不提供“队列-交换机”直连绑定的动态接口，但支持交换机之间的绑定——而 RabbitMQ 的经典模式中，**队列与交换机的绑定本质是通过 QueueBind / QueueUnbind 完成的**，不是交换机间绑定。很多人误查 ExchangeBind，结果白忙活。
正确做法是调用 Channel.QueueBind 添加绑定，用 Channel.QueueUnbind 移除绑定。这两个方法在连接活跃、Channel 有效时可随时调用，无需重启或重建 Channel。
-
QueueBind的routingKey参数必须与你发布消息时使用的 key 一致，否则路由失效 -
QueueUnbind不接受args参数，所以当初用args声明的绑定（如x-match: all）无法被精准解绑——它只按queue、exchange、routingKey三元组匹配 - 多次对同一三元组调用
QueueBind是幂等的；但重复QueueUnbind会返回amqp.ErrNoRoute错误，需捕获处理
绑定前必须确保交换机和队列已存在
RabbitMQ 不允许绑定不存在的交换机或队列。QueueBind 调用时如果任一端未声明，会返回 amqp.NotFound。这不是网络问题，是服务端校验。
常见错误现象：Exception (404) Reason: "NOT_FOUND - no exchange 'my-exchange' in vhost '/'" 或类似队列未找到提示。
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 先用
Channel.ExchangeDeclare声明交换机，Channel.QueueDeclare声明队列（哪怕只是Passive: true检查存在性） - 若队列是持久化的，绑定时
QueueBind不会自动创建它，必须提前存在 - 临时队列（
exclusive: true）一旦 Channel 关闭即销毁，此时再调用QueueUnbind会失败，应避免在 Channel 生命周期外操作
解绑后消息不再路由到该队列，但已有未确认消息不受影响
QueueUnbind 是立即生效的：此后发布的消息，只要 routing key 匹配，就不会再进入该队列。但它**不会清空队列、不会拒绝已有消息、也不会触发 requeue**。
这意味着：解绑前已入队但未被消费/确认的消息，仍保留在队列中，消费者还能正常获取。
- 如果想彻底切断某队列的输入流，解绑是充分且必要的；但若还想清理积压，得额外调用
Channel.QueuePurge - 解绑操作本身不阻塞，但受 RabbitMQ 服务端顺序执行约束——同一 Channel 上连续的
QueueBind+QueueUnbind会按序生效，不会出现“中间态路由混乱” - 跨 Channel 解绑可行，但必须使用同一个 vhost 和同名资源；不同 Channel 之间无状态共享，也无并发冲突
注意 AMQP 0.9.1 协议限制：没有“列出当前所有绑定”的 API
你无法通过客户端代码主动查询某个队列当前绑定了哪些交换机、用了什么 routing key。RabbitMQ 管理插件（HTTP API 或 Web UI）能查，但 Go SDK 没封装对应接口。
这意味着动态管理绑定时，**必须自己维护绑定关系的状态映射表**，否则解绑容易误操作。
- 建议用
map[string]map[string]map[string]bool（vhost → exchange → queue → bound）这类结构缓存已知绑定 - 每次
QueueBind成功后更新缓存；QueueUnbind前先查缓存，避免对不存在的绑定重复操作 - 服务重启后缓存丢失，需结合初始化逻辑（如预绑定清单）或依赖管理 API 同步恢复，不能假定 RabbitMQ 会“记住你的 bind 操作历史”
