事务消息启动前须确认三件事：一要先启动nameserver再启动broker并正确配置-n参数；二要设置brokerip1为真实可访问ip而非127.0.0.1；三需jdk 8+且jvm元空间配置合理避免oom。
事务消息环境启动前必须确认的三件事
RocketMQ 事务消息不是加个依赖就能用的功能，它依赖完整的底层服务链路。没跑通 NameServer 和 Broker，TransactionMQProducer 一初始化就会抛 No route info of this topic 或直接超时连接失败。
- 必须先启动
mqnamesrv，再启动mqbroker，且mqbroker启动命令里要带-n localhost:9876（或你实际的 nameserver 地址），否则事务生产者根本找不到路由 - Broker 配置文件（如
broker.conf）中brokerIP1必须设为本机可被客户端访问的真实 IP（不能写127.0.0.1，尤其在 Docker 或远程调用场景下） - Java 环境必须是 JDK 8+，且
JAVA_HOME已正确配置；RocketMQ 4.9.4+ 对 JVM 元空间大小敏感，runbroker.sh里若还保留-XX:MaxMetaspaceSize=320m这类低配参数，启动后可能立刻 OOM 并静默退出
依赖版本和 TransactionMQProducer 初始化要点
用错依赖版本是事务消息“回调不触发”最常见原因——rocketmq-client 和 rocketmq-acl 必须严格 ≥ 4.9.4，且两个版本号完全一致。4.9.3 及以下不支持 TransactionListener 的完整回查语义。
- pom.xml 中必须同时引入两个依赖：
rocketmq-client和rocketmq-acl，缺一不可；ACL 包负责权限校验，没它事务消息发不出去（报NO_PERMISSION） -
TransactionMQProducer构造时传入的group名必须全局唯一，且不能与普通DefaultMQProducer共用同一个 group，否则事务状态无法隔离 - 必须显式调用
producer.setTransactionListener(...)，且 listener 实例不能是匿名内部类（会影响序列化与回查上下文）
executeLocalTransaction 和 checkLocalTransaction 的行为边界
这两个方法不是“随便写个数据库操作就行”，它们决定了事务最终是提交、回滚还是挂起等待重试。很多人卡在 checkLocalTransaction 不被调用，其实是因为 executeLocalTransaction 返回了 COMMIT_MESSAGE 或 ROLLBACK_MESSAGE ——一旦返回确定态，Broker 就不再回查。
-
executeLocalTransaction里只做**本地事务尝试**，比如更新订单表状态为“支付中”，但**不要 commit**；返回UNKNOW才会触发后续回查 -
checkLocalTransaction必须是幂等查询，例如查订单 DB 当前状态是否为“已支付”，不能在里面做任何写操作，也不能抛出未捕获异常（会当成回查失败，触发多次重试） - 回查方法里若查不到数据，应返回
ROLLBACK_MESSAGE，而不是UNKNOW；否则 Broker 会持续每 60 秒回查一次，最长持续 15 小时（默认配置）
本地调试时最容易忽略的配置项
开发阶段用 localhost 启动 RocketMQ 很方便，但事务消息对网络连通性更敏感。一个看似无关的配置项，常导致“半消息发出去了，但 executeLocalTransaction 死活不回调”。
立即学习“Java免费学习笔记（深入）”；
-
broker.conf中必须设置transactionCheckInterval=60000（单位毫秒），这是回查触发间隔；默认值是 60000，但如果被注释或改成了 0，回查就永远不会发生 -
transactionCheckMax=15控制最大回查次数，别轻易调大；线上环境建议保持默认，避免因 DB 假死导致无限轮询 - 消费者端如果用的是
DefaultMQPushConsumer，确保其subscribe的 topic 和 tag 能匹配到事务提交后的消息；事务消息和普通消息在协议层没有本质区别，只是多了一次状态协商
事务消息真正的复杂点不在代码，而在状态机的生命周期管理：半消息 → 本地事务执行 → 回查 → 提交/回滚。任何一个环节的网络抖动、超时阈值、DB 事务隔离级别偏差，都可能让消息卡在中间态。上线前务必用 rocketmq-console 查看 RMQ_SYS_TRANS_HALF_TOPIC 里的堆积情况。
