除非已有java生态强依赖，否则不建议新go微服务项目选用activemq；其go支持弱、运维复杂、社区冷清，且stomp/amqp对接易现连接闪断、ack不一致、dlq配置失效等问题。
ActiveMQ在Golang微服务里到底该不该用
直接说结论：除非你已有Java生态强依赖（比如大量遗留JMS客户端、Spring Boot服务共存），否则不建议新项目选ActiveMQ。它对Go生态支持弱、运维复杂度高、社区活跃度远低于RabbitMQ/Kafka/NATS。Golang调用ActiveMQ主要靠STOMP或AMQP协议，但go-stomp和streadway/amqp对接ActiveMQ时经常遇到连接闪断、ACK语义不一致、死信配置失效等问题。
如果非要用，必须改掉默认JVM内存配置
ActiveMQ默认JVM堆设为512MB，启动后几分钟内就会因消息积压触发Full GC，导致生产者发送超时、消费者断连。企业级部署必须重配：activemq.xml里要关掉producerFlowControl（否则发消息卡住），并显式设置memoryLimit：
<policyentry queue=">" producerflowcontrol="false" memorylimit="128mb"><pendingqueuepolicy><vmqueuecursor></vmqueuecursor></pendingqueuepolicy></policyentry>
同时启动参数加-Xms2g -Xmx4g -XX:+UseG1GC，不然OutOfMemoryError: Direct buffer memory会频繁报错。
Go客户端必须绕开JMS，走STOMP+TLS才稳
ActiveMQ原生JMS接口对Go不友好，强行用github.com/go-stomp/stomp库时要注意三点：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
Connect()必须传stomp.ConnOpt.Login("admin", "admin")，默认凭据在conf/jetty-realm.properties里，别用空密码 - 订阅Topic时用
Subscribe("/topic/user.login", map[string]string{"ack": "client-individual"})，不能用auto模式，否则ACK丢失会导致重复消费 - 发消息前手动加
content-type: application/json头，否则Go解码JSON会报invalid character 'S' looking for beginning of value
死信队列(DLQ)配置在ActiveMQ里是坑中坑
ActiveMQ的DLQ不是自动创建的，必须在activemq.xml里手动声明deadLetterStrategy，且路径必须匹配队列名规则：
<deadletterstrategy><individualdeadletterstrategy queueprefix="DLQ." usequeuefortopicmessages="true"></individualdeadletterstrategy></deadletterstrategy>
然后Go消费者处理失败时，得主动调用conn.Send("/queue/DLQ.my_order_queue", ...)投递，不能指望Broker自动转移——因为ActiveMQ的AMQP插件对x-dead-letter-exchange支持不全，streadway/amqp发的消息带这个header会被静默丢弃。
真正麻烦的是：ActiveMQ没有类似RabbitMQ的requeue=false + basic.nack原子操作，每次失败都要自己建连接、发消息、关连接，一不留神就堆积在DLQ里没人管。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
