RocketMQ的Tag是构建生产者与消费者轻量级契约的关键机制，需与Topic明确分工：Topic为物理隔离层（业务域），Tag为逻辑分类层（具体动作）；不同业务域必须分Topic，同一Topic下Tag应语义明确、互斥可枚举，命名规范统一（如tag_order_created），订阅须精准（避免“*”通吃），复杂过滤应转用SQL92表达式。
RocketMQ 的消息过滤能力核心在于 Tag 的合理设计与使用。它不是简单的“打标签”，而是构建生产者与消费者之间轻量级契约的关键机制。用得好，能大幅降低消息误投、减少无效消费、提升系统可维护性；用得随意，反而会埋下耦合隐患或过滤失效风险。
Tag 与 Topic 的分工必须清晰
Topic 是物理隔离层，代表业务域；Tag 是逻辑分类层，代表该域内的具体动作。二者不能混用，也不能越界替代。
- 不同业务领域（如订单、库存、用户）必须用不同 Topic，不能全塞进一个 Topic 再靠 Tag 区分
- 同一 Topic 下，Tag 应表达语义明确、互斥且可枚举的子事件，例如 ORDER_CREATED、ORDER_PAID、ORDER_REFUNDED
- 避免用 Tag 表达状态变化（如 “status=1”、“status=2”），这属于消息体内容或 SQL 过滤范畴，Tag 应保持静态、语义化
- 不建议在同一个 Topic 中混用事务消息和普通消息——它们类型不同，必须走不同 Topic
Tag 命名要规范、可读、可扩展
Tag 不是随便起的字符串，它是消费端订阅的依据，也是团队协作的隐式接口。
- 命名格式统一推荐：tag_ + 业务动作小写蛇形，例如 tag_order_created、tag_payment_success
- 避免使用模糊词（如 “update”、“info”、“event”），应明确动作主体与行为，如 tag_inventory_deduct 比 tag_update 更可靠
- 同一业务流中，Tag 应体现流程顺序或因果关系，便于理解消息流向，例如 tag_order_submitted → tag_payment_received → tag_order_confirmed
- 新增 Tag 无需改 Topic 或重启服务，但需同步更新消费者订阅表达式，并做好灰度验证
消费者订阅要精准，别“通吃”
默认订阅 "*" 看似省事，实则破坏了消息路由的边界，是多数线上问题的源头。
- 每个消费者应只订阅自己真正需要的 Tag，例如物流服务只订阅 tag_order_shipped 和 tag_order_delivered
- 多个 Tag 订阅用 || 连接，如 "tag_order_shipped || tag_order_returned"；RocketMQ 5.x 后建议封装为 FilterExpression 对象传入
- 不要依赖客户端代码 if-else 过滤：Broker 端已支持 Tag 过滤，把无关消息挡在传输链路之外，能显著降低网络开销与消费端 CPU 压力
- 订阅表达式必须与生产者设置的 Tag 完全一致（区分大小写），建议常量定义复用，避免硬编码散落各处
Tag 过滤的局限与替代方案
Tag 是轻量高效的选择，但不是万能的。遇到复杂条件时，需及时切换策略。
- Tag 只支持字符串精确匹配或简单 OR 表达式，不支持范围查询、模糊匹配、数值比较等
- 若需按消息属性（如 orderAmount > 100、region = "shanghai"）过滤，应改用 SQL92 表达式过滤，并在发送时通过 putUserProperty 设置属性
- 高频变更的过滤逻辑（如按用户等级动态分流）不适合用 Tag，更适合在消费端做二次路由，或引入规则引擎
- Tag 为空时，Broker 视为无标签消息，无法被任何非 "*" 的 Tag 表达式匹配到，因此生产者务必确保每条消息都设 Tag
