RocketMQ 系列文章（进阶篇第 4 篇）：死信队列与延迟消息实战指南

qq_297574672026-04-23 10:31

前言：从"异常处理"到"定时调度"的进阶突破

在上一篇中，我们掌握了 RocketMQ 消息过滤与消息回溯的核心原理与实操，实现了"精准消费"与"历史消息找回"，解决了业务场景中无效消费和消息丢失的问题。但在生产环境中，还有两个高频痛点亟待解决：一是消息消费失败后，如何避免无限重试导致系统雪崩，同时妥善处理异常消息；二是如何实现"定时执行"的业务需求，如订单超时未支付自动取消、定时通知、任务延迟执行等。

例如：电商场景中，用户下单后未在30分钟内支付，需要自动取消订单并恢复库存；物流场景中，包裹出库后2小时需向用户发送提醒消息；系统运维场景中，需在凌晨2点执行数据备份任务。这些场景若通过传统定时任务实现，不仅开发繁琐，还会面临分布式环境下的时钟同步、任务幂等、集群部署等问题。

为解决上述问题，RocketMQ 提供了**死信队列（Dead-Letter Queue，DLQ）和延迟消息（Delayed Message）**两大核心特性：死信队列负责"异常消息兜底"，将消费失败的消息妥善保存，避免无限重试和消息丢失；延迟消息负责"定时调度"，实现消息的延迟投递与执行，替代传统定时任务，提升系统灵活性和可靠性。

本篇将从原理、特性、实操三个维度，深度解析死信队列与延迟消息，结合电商、物流等实际业务场景，手把手教你落地异常消息处理和定时调度方案，进一步完善 RocketMQ 生产环境落地能力，让消息队列真正成为分布式系统的"稳定基石"。

前置要求：

  1. 已掌握 RocketMQ 基础 API 开发、消息过滤与消息回溯的核心原理与实操

  2. 已部署 RocketMQ 高可用集群（Dledger 或多主多从模式均可）

  3. 已掌握 SpringBoot 整合 RocketMQ 的开发方式，具备简单的 Java 开发和问题排查能力

  4. 了解分布式系统中异常处理和定时任务的常见痛点

一、死信队列（DLQ）：异常消息的"兜底容器"

死信队列，本质是 RocketMQ 为消费失败的消息提供的"兜底存储容器"。当一条消息被消费者多次消费仍失败，且无法通过重试机制恢复时，RocketMQ 会将该消息转入死信队列，避免无限重试占用系统资源，同时便于开发人员后续排查异常、手动处理，确保消息不丢失、系统稳定运行。

1.1 死信队列的核心原理

死信队列的核心逻辑是"重试失败 → 标记死信 → 转入专用队列 → 人工处理"，其运作流程如下：

  1. 消息发送到 Broker 后，消费者尝试消费该消息，但因业务异常（如数据库宕机、参数错误）、系统异常等原因消费失败。

  2. RocketMQ 会自动对消费失败的消息进行重试（默认重试 16 次，重试间隔逐渐延长）。

  3. 若消息经过最大重试次数后，仍消费失败，RocketMQ 会将该消息标记为"死信消息"（Dead-Letter Message）。

  4. 死信消息会被自动转入该消费者组对应的死信队列，死信队列是一种特殊的 Topic，命名规则为"%DLQ%+消费者组名"（如 %DLQ%logistics-consumer-group）。

  5. 开发人员可通过监听死信队列，排查消息消费失败的原因，处理完成后，可手动将消息重新投递到原 Topic，或直接处理业务逻辑。

1.2 死信队列的核心特性

  • 自动创建：死信队列无需手动创建，当消息成为死信消息时，RocketMQ 会自动创建对应的死信队列（每个消费者组对应一个死信队列）。

  • 专属消费：死信队列仅存储对应消费者组消费失败的死信消息，不同消费者组的死信消息相互隔离，互不影响。

  • 持久化存储：死信消息会像普通消息一样持久化到 Broker 的 CommitLog 中，默认存储 72 小时（可配置），确保消息不丢失。

  • 手动处理：死信队列中的消息不会被自动消费，需开发人员手动监听、排查异常、处理消息，避免误处理导致业务异常。

1.3 死信消息的产生条件（必记）

并非所有消费失败的消息都会成为死信消息，只有满足以下条件之一，消息才会被标记为死信，转入死信队列：

  • 消息经过 RocketMQ 最大重试次数（默认 16 次）后，仍消费失败。

  • 消费者在消费消息时，主动拒绝消费（返回 CONSUME_REJECTED），且不希望重试。

  • 消息在 Broker 中存储时间超过预设的消息过期时间（若配置了消息过期），未被消费。

核心提醒 ：

死信队列的核心作用是"兜底"，而非"自动修复"。其目的是避免消费失败的消息无限重试占用系统资源，同时保留异常消息供排查，最终仍需人工介入处理异常原因，确保业务闭环。

1.4 死信队列与普通队列的区别

队列类型 核心作用 消息来源 消费方式
普通队列 存储正常发送的消息，供消费者正常消费 生产者主动发送的消息 消费者自动监听、消费
死信队列 存储消费失败的死信消息，兜底备份 普通队列中消费失败、重试无效的消息 人工监听、手动处理

二、延迟消息：分布式定时任务的"最优解"

延迟消息，指生产者发送消息后，Broker 不会立即将消息投递到消费者，而是根据预设的延迟时间，在指定时间后再将消息投递，供消费者消费。延迟消息本质是"定时投递"，可替代传统的分布式定时任务，解决定时任务的时钟同步、幂等性、集群部署等痛点，实现高效、可靠的定时调度。

2.1 延迟消息的核心原理

RocketMQ 的延迟消息采用"分级延迟"机制，而非任意时间延迟，核心原理如下：

  1. 生产者发送消息时，指定消息的延迟级别（而非具体延迟时间），Broker 接收消息后，不会立即将消息放入目标 Topic 的 ConsumeQueue 中。

  2. Broker 会将延迟消息暂时存储在内部的"延迟消息队列"（一个特殊的 Topic：SCHEDULE_TOPIC_XXXX）中，并根据延迟级别，确定消息的投递时间。

  3. Broker 内部有一个定时任务线程池，定期扫描延迟消息队列，判断消息是否达到投递时间。

  4. 当消息达到预设的延迟时间后，Broker 会将消息从延迟消息队列中取出，投递到目标 Topic 的 ConsumeQueue 中，供消费者正常消费。

2.2 延迟级别的划分（必记）

RocketMQ 不支持任意时间的延迟，仅支持预设的延迟级别，默认分为 18 级（可通过 Broker 配置修改），各级别对应的延迟时间如下（默认配置）：

延迟级别 延迟时间 适用场景
1 1秒 短时间延迟通知（如登录成功后1秒推送欢迎消息）
2 5秒 短时间重试（如接口调用失败后5秒重试）
3 10秒 短时间延迟校验（如验证码发送后10秒校验）
4 30秒 订单创建后30秒未支付提醒
5 1分钟 短时间延迟处理（如订单提交后1分钟确认）
6-18 2分钟、3分钟、5分钟...2小时（逐级递增） 长时间延迟（如订单超时30分钟取消、物流2小时提醒）

注意 ：

若默认的延迟级别无法满足业务需求，可通过修改 Broker 配置文件（broker.conf）中的"messageDelayLevel"参数，自定义延迟级别（如调整延迟时间、增加/减少级别），修改后需重启 Broker 生效。

2.3 延迟消息的核心特性

  • 分级延迟：仅支持预设的延迟级别，不支持任意时间延迟，确保延迟消息的高效调度。

  • 可靠投递：延迟消息会持久化到 CommitLog 中，即使 Broker 宕机，重启后仍能正常投递，确保消息不丢失。

  • 幂等性保障：延迟消息可能因 Broker 异常导致重复投递，需消费者保证幂等性，避免重复处理业务。

  • 无侵入性：无需额外部署定时任务框架，基于 RocketMQ 自身机制实现定时调度，降低系统复杂度。

2.4 延迟消息 vs 传统定时任务

在分布式系统中，传统定时任务（如 Spring Schedule）存在诸多痛点，而延迟消息可完美解决，两者对比如下：

对比维度 传统定时任务（Spring Schedule） RocketMQ 延迟消息
集群部署 需额外处理分布式锁，避免重复执行 天然支持集群，Broker 统一调度，无重复执行问题
时钟同步 依赖集群节点时钟同步，时钟偏差会导致任务执行异常 基于 Broker 时钟调度，无需节点时钟同步
任务灵活度 固定频率执行，无法根据业务场景动态调整 按需发送，每个消息可设置不同延迟级别，灵活适配业务
可靠性 节点宕机后，任务会丢失，需额外做持久化 消息持久化，Broker 高可用，任务不会丢失

三、实操：死信队列与延迟消息代码实现（Java 版）

本次实操基于 RocketMQ 4.8.0 版本，结合 SpringBoot 整合方式，延续之前的电商场景，实现"订单超时取消（延迟消息）"和"异常消息处理（死信队列）"，分为 4 部分：死信队列实操、延迟消息实操、异常处理与消息重投、幂等性保障。

环境准备：沿用上一篇的 SpringBoot 项目、RocketMQ 集群，无需额外新增依赖，仅需根据需求调整配置。

3.1 死信队列实操（异常消息处理）

本次实操模拟"物流服务消费订单消息时，因数据库宕机导致消费失败，消息重试16次后转入死信队列，最终人工处理"的场景。

3.1.1 步骤 1：配置消费者（设置重试次数）

修改物流服务消费者，设置消息重试次数（默认16次，可自定义），并模拟消费失败场景：

bash 复制代码 
import org.apache.rocketmq.spring.annotation.RocketMQMessageListener;
import org.apache.rocketmq.spring.core.RocketMQListener;
import org.springframework.stereotype.Component;

@Component
@RocketMQMessageListener(
        topic = "order_filter_topic",
        selectorExpression = "order:create",
        consumerGroup = "logistics-consumer-group",
        maxReconsumeTimes = 3 // 自定义重试次数（简化测试，设为3次，实际生产建议用默认16次）
)
public class LogisticsConsumer implements RocketMQListener<String> {

    @Override
    public void onMessage(String orderId) {
        try {
            // 模拟消费失败（如数据库宕机、业务异常）
            throw new RuntimeException("数据库宕机，消费失败");
        } catch (Exception e) {
            e.printStackTrace();
            // 消费失败，抛出异常，触发 RocketMQ 重试
            throw new RuntimeException("订单" + orderId + "消费失败，触发重试");
        }
    }
}

3.1.2 步骤 2：发送测试消息，触发死信

沿用之前的生产者代码，发送一条订单创建消息，触发消费失败和重试：

bash 复制代码 
// 测试接口，发送订单创建消息
@PostMapping("/test/deadLetter")
public String testDeadLetter(@RequestParam String orderId) {
    // 发送订单创建消息（Tag：order:create）
    orderFilterProducer.sendOrderMessageWithTag(orderId, "order:create", 800.0);
    return "测试消息发送成功，等待消费重试与死信转入";
}

3.1.3 步骤 3：监听死信队列，处理异常消息

死信队列的命名规则为"%DLQ%+消费者组名"，即"%DLQ%logistics-consumer-group"，编写死信队列监听器，排查异常并处理：

bash 复制代码 
import org.apache.rocketmq.spring.annotation.RocketMQMessageListener;
import org.apache.rocketmq.spring.core.RocketMQListener;
import org.springframework.stereotype.Component;

// 监听死信队列：%DLQ% + 原消费者组名
@Component
@RocketMQMessageListener(
        topic = "%DLQ%logistics-consumer-group",
        consumerGroup = "dlq-logistics-consumer-group", // 死信消费者组，与原组区分
        messageModel = "CLUSTERING"
)
public class DLQLogisticsConsumer implements RocketMQListener<String> {

    @Override
    public void onMessage(String orderId) {
        // 1. 排查消费失败原因（如检查数据库、业务逻辑）
        System.out.println("监听到死信消息，订单ID：" + orderId);
        System.out.println("开始排查消费失败原因：数据库是否正常、业务参数是否正确...");

        // 2. 模拟异常处理（如修复数据库、调整业务逻辑）
        System.out.println("异常原因排查完成：数据库宕机已修复，开始重新处理订单");

        // 3. 手动处理业务（如重新安排物流）
        System.out.println("订单" + orderId + "死信消息处理完成，已重新安排物流");

        // 可选：将消息重新投递到原 Topic，供原消费者重新消费
        // rocketMQTemplate.syncSend("order_filter_topic:order:create", orderId);
    }
}

3.1.4 测试验证（死信队列）

  1. 调用 /test/deadLetter 接口，发送测试消息。

  2. 观察日志，消息会重试 3 次（配置的 maxReconsumeTimes），均失败。

  3. 消息被标记为死信，自动转入死信队列"%DLQ%logistics-consumer-group"。

  4. 死信监听器 DLQLogisticsConsumer 监听到消息，输出排查和处理日志，完成死信处理。

3.2 延迟消息实操（订单超时取消）

本次实操模拟"电商订单创建后，30分钟内未支付，自动取消订单并恢复库存"的场景，使用延迟消息实现（延迟级别 4，对应 30 秒，简化测试；实际生产用级别 8，对应 30 分钟）。

3.2.1 步骤 1：生产者发送延迟消息

编写延迟消息生产者，发送订单创建消息时，指定延迟级别，同时发送延迟消息（用于超时取消）：

bash 复制代码 
import org.apache.rocketmq.spring.core.RocketMQTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.messaging.Message;
import org.springframework.messaging.support.MessageBuilder;
import org.springframework.stereotype.Component;

@Component
public class DelayMessageProducer {

    @Autowired
    private RocketMQTemplate rocketMQTemplate;

    /**
     * 发送订单延迟消息（用于超时取消）
     * @param orderId 订单ID
     * @param delayLevel 延迟级别（4=30秒，8=30分钟）
     */
    public void sendOrderDelayMessage(String orderId, int delayLevel) {
        // 构建延迟消息（消息体为订单ID）
        Message<String> message = MessageBuilder
                .withPayload(orderId)
                .build();

        // 发送延迟消息：指定延迟级别，syncSend 第三个参数为延迟级别
        rocketMQTemplate.syncSend("order_delay_topic", message, 3000, delayLevel);
        System.out.println("订单延迟消息发送成功，订单ID：" + orderId + "，延迟级别：" + delayLevel);
    }
}

3.2.2 步骤 2：消费者监听延迟消息，处理订单取消

编写延迟消息消费者，监听"order_delay_topic"，接收延迟消息后，执行订单取消和库存恢复逻辑：

bash 复制代码 
import org.apache.rocketmq.spring.annotation.RocketMQMessageListener;
import org.apache.rocketmq.spring.core.RocketMQListener;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Component;

@Component
@RocketMQMessageListener(
        topic = "order_delay_topic",
        consumerGroup = "order-delay-consumer-group"
)
public class OrderDelayConsumer implements RocketMQListener<String> {

    @Autowired
    private OrderService orderService; // 订单服务（取消订单）
    @Autowired
    private StockService stockService; // 库存服务（恢复库存）
    @Autowired
    private StringRedisTemplate redisTemplate;

    // 幂等性 key 前缀（避免延迟消息重复投递导致重复取消）
    private static final String DELAY_IDEMPOTENT_KEY = "order:delay:cancel:";

    @Override
    public void onMessage(String orderId) {
        // 1. 幂等性校验：避免重复取消订单
        String key = DELAY_IDEMPOTENT_KEY + orderId;
        Boolean isCanceled = redisTemplate.hasKey(key);
        if (Boolean.TRUE.equals(isCanceled)) {
            System.out.println("订单" + orderId + "已取消，跳过重复处理");
            return;
        }

        // 2. 查询订单状态：判断订单是否已支付（未支付则取消）
        OrderDTO order = orderService.getOrderById(orderId);
        if (order == null) {
            System.out.println("订单" + orderId + "不存在，无需处理");
            return;
        }

        // 3. 未支付，执行取消逻辑
        if (order.getOrderStatus() == 0) { // 0-待支付
            orderService.cancelOrder(orderId); // 取消订单
            stockService.restoreStock(order.getProductId(), 1); // 恢复库存
            System.out.println("订单" + orderId + "超时未支付，已取消并恢复库存");

            // 4. 标记订单已取消（幂等性保障）
            redisTemplate.opsForValue().set(key, "1", 24, java.util.concurrent.TimeUnit.HOURS);
        } else {
            // 已支付，无需处理
            System.out.println("订单" + orderId + "已支付，无需取消");
        }
    }
}

3.2.3 步骤 3：完善订单与库存服务（取消+恢复）

补充订单取消和库存恢复的方法，确保业务闭环：

bash 复制代码 
// 订单服务新增取消订单方法
@Service
public class OrderService {
    // 省略原有方法...

    /**
     * 取消订单（修改订单状态为2-已取消）
     */
    @Transactional(rollbackFor = Exception.class)
    public void cancelOrder(String orderId) {
        jdbcTemplate.update(
                "update `order` set order_status = 2 where id = ?",
                orderId
        );
    }
}

// 库存服务新增恢复库存方法
@Service
public class StockService {
    // 省略原有方法...

    /**
     * 恢复库存（订单取消后）
     */
    @Transactional(rollbackFor = Exception.class)
    public void restoreStock(String productId, int num) {
        jdbcTemplate.update(
                "update stock set stock_num = stock_num + ? where product_id = ?",
                num,
                productId
        );
    }
}

3.2.4 测试验证（延迟消息）

  1. 调用订单创建接口，生成待支付订单（orderStatus=0），同时调用延迟消息生产者，发送延迟级别为4（30秒）的消息。

  2. 30秒内不支付订单，观察延迟消息消费者日志，会自动取消订单、恢复库存。

  3. 30秒内支付订单（修改orderStatus=1），观察日志，延迟消息消费时会判断订单状态，无需取消。

  4. 模拟延迟消息重复投递（如Broker异常），验证幂等性，确保不会重复取消订单。

3.3 异常处理与消息重投（生产必备）

3.3.1 死信消息重投

死信消息处理完成后，若需将消息重新投递到原 Topic，供原消费者重新消费，可在死信监听器中添加重投逻辑：

bash 复制代码 
// 死信监听器中添加重投逻辑
@Autowired
private RocketMQTemplate rocketMQTemplate;

@Override
public void onMessage(String orderId) {
    try {
        // 排查异常、处理业务...
        System.out.println("订单" + orderId + "死信消息处理完成");

        // 重新投递到原 Topic，供原消费者重新消费
        rocketMQTemplate.syncSend("order_filter_topic:order:create", orderId);
        System.out.println("订单" + orderId + "已重新投递到原 Topic");
    } catch (Exception e) {
        e.printStackTrace();
        // 重投失败，可记录日志，人工再次处理
    }
}

3.3.2 延迟消息异常处理

延迟消息消费失败时，会触发重试，重试失败后会转入对应的死信队列，需单独监听延迟消息的死信队列：

bash 复制代码 
// 监听延迟消息的死信队列
@Component
@RocketMQMessageListener(
        topic = "%DLQ%order-delay-consumer-group",
        consumerGroup = "dlq-order-delay-consumer-group"
)
public class DLQOrderDelayConsumer implements RocketMQListener<String> {

    @Override
    public void onMessage(String orderId) {
        System.out.println("监听到延迟消息死信，订单ID：" + orderId);
        // 排查消费失败原因（如订单不存在、库存异常）
        // 手动处理，如人工取消订单、通知运营人员
    }
}

四、生产环境落地注意事项（避坑指南）

4.1 死信队列注意事项

  • 合理设置重试次数：根据业务场景设置 maxReconsumeTimes，避免重试次数过多（如16次）导致系统资源占用，也避免次数过少（如1次）导致正常临时异常的消息被误判为死信。

  • 死信消息及时处理：死信队列中的消息需定期监听、处理，避免消息堆积过多占用磁盘空间；同时做好死信消息的日志记录，便于排查异常原因。

  • 死信队列隔离：不同业务线的死信队列需通过消费者组隔离，避免死信消息混淆；死信消费者组需与原消费者组区分，防止影响原业务消费。

  • 避免死信消息循环重投：死信消息重投时，需确保原消费者的异常已修复，否则会再次消费失败，重新转入死信队列，形成循环。

4.2 延迟消息注意事项

  • 延迟级别选择：根据业务需求选择合适的延迟级别，避免使用过高或过低的级别；若默认级别无法满足，可自定义延迟级别，但需注意调整 Broker 配置后重启生效。

  • 幂等性必须保障：延迟消息可能因 Broker 异常、网络波动导致重复投递，消费者必须实现幂等性校验（如基于订单ID、消息ID），避免重复处理业务（如重复取消订单、重复恢复库存）。

  • 延迟消息精度：RocketMQ 延迟消息的精度为秒级，无法达到毫秒级精度，不适用于对时间精度要求极高的场景（如金融交易定时）。

  • 避免大量延迟消息堆积：若存在大量延迟消息，会占用 Broker 资源，影响延迟消息的投递效率；建议对大量延迟消息进行分批处理，或优化业务逻辑。

4.3 性能优化建议

  • 死信队列优化：死信队列的存储时间可根据业务需求调整（默认72小时），核心业务可适当延长，非核心业务可缩短，避免磁盘空间浪费；同时定期清理已处理的死信消息。

  • 延迟消息优化：避免使用过高的延迟级别（如2小时以上），若需长时间延迟，可采用"多次延迟"的方式（如先延迟1小时，消费后再延迟1小时），提升投递效率；同时将延迟消息的 Topic 与普通消息 Topic 隔离，便于监控。

  • 监控优化：通过 RocketMQ 控制台，监控死信队列的消息数量、延迟消息的投递情况，及时发现异常（如死信消息激增、延迟消息投递延迟）；同时做好日志监控，记录死信消息和延迟消息的处理过程。

4.4 常见坑点规避

  • 坑点1：死信队列未监听，导致死信消息堆积，无法处理。规避：必须为每个消费者组配置死信监听器，定期处理死信消息。

  • 坑点2：延迟消息发送时，误将延迟级别设为0（0表示不延迟），导致消息立即投递。规避：明确延迟级别对应关系，发送前校验延迟级别。

  • 坑点3：消费者未实现幂等性，延迟消息重复投递导致业务异常。规避：所有延迟消息和死信消息的消费者，必须添加幂等性校验。

  • 坑点4：自定义延迟级别后，未重启 Broker，导致配置不生效。规避：修改 Broker 配置后，必须重启 Broker，确保延迟级别生效。

五、本篇核心总结及下一篇预告

死信队列是异常消息的"兜底容器"，核心解决消费失败消息的无限重试和消息丢失问题，消息重试达到最大次数后自动转入死信队列，需人工监听、处理。

  • 延迟消息是分布式定时任务的"最优解"，采用分级延迟机制，实现消息的定时投递，替代传统定时任务，解决集群部署、时钟同步等痛点，支持可靠投递。

  • 实操关键：死信队列需配置消费者重试次数、监听死信 Topic；延迟消息需指定延迟级别、实现消费者幂等性，同时完善异常处理和消息重投逻辑。

  • 生产落地：重点关注重试次数配置、幂等性保障、死信消息及时处理、延迟级别选择，做好监控和日志，规避常见坑点，确保系统稳定运行。

下一篇，我们将讲解 RocketMQ 高级特性------高可用集群部署与运维监控，解决"集群稳定性"和"运维排查"问题，实现 RocketMQ 生产环境的高可用落地，为分布式系统提供可靠的消息支撑。

相关推荐
KAI丶6 小时前
【RocketMQ】dashboard消息展示重复
rocketmq
Wmenghu6 小时前
Ubuntu 安装 RocketMQ 5.x + Dashboard 完整教程
linux·ubuntu·rocketmq
QC·Rex2 天前
消息队列架构设计 - Kafka/RocketMQ/RabbitMQ 深度对比与实战
kafka·rabbitmq·rocketmq
qq_297574675 天前
RocketMQ系列文章（入门篇第6篇）：延时消息+顺序消息实战
spring boot·rocketmq·java-rocketmq
刘~浪地球9 天前
消息队列--RocketMQ 架构设计与优化
架构·rocketmq
Rick199311 天前
rabbitmq, rocketmq, kafka这三种消息如何分别保住可靠性，顺序性，以及应用场景？
kafka·rabbitmq·rocketmq
有梦想的小何12 天前
从0到1搭建可靠消息链路：RocketMQ重试 + Redis幂等实战
java·redis·bootstrap·rocketmq
鬼先生_sir13 天前
SpringCloud-Stream + RocketMQ/Kafka
spring cloud·kafka·rocketmq·stream
小江的记录本17 天前
【RocketMQ】RocketMQ核心知识体系全解（5大核心模块：架构模型、事务消息两阶段提交、回查机制、延迟消息、顺序消息）
linux·运维·服务器·前端·后端·架构·rocketmq
热门推荐
012026年4月技术前沿：AI大模型爆发、智能体革命与量子安全新纪元02GitHub 镜像站点032026年4月AI大事件深度解读：大模型竞争进入“深水区“04近期有什么ai的新消息，新动态？ 2026.4月052026 年 AI 编程助手全面对比评测：Cursor vs Copilot vs Claude Code vs GitHub Copilot Free06AI Weekly | 2026年4月第二周 · GitHub热门项目与AI发展趋势深度解析07CC-Switch & Claude 基于 Linux 服务器安装使用指南08从限购到畅通：GLM-5.1 Coding Plan接入攻略09Claude Code Windows 兼容性问题：指定版本 2.1.112 可解决10UBUNTU Claude Code 报错 claude native binary not installed