RabbitMQ - SpringCloud 集成 RabbitMQ：微服务场景实践

Ne0inhk

— 20 min read
RabbitMQ - SpringCloud 集成 RabbitMQ：微服务场景实践
在这里插入图片描述
👋 大家好，欢迎来到我的技术博客！
📚 在这里，我会分享学习笔记、实战经验与技术思考，力求用简单的方式讲清楚复杂的问题。
🎯 本文将围绕RabbitMQ这个话题展开，希望能为你带来一些启发或实用的参考。
🌱 无论你是刚入门的新手，还是正在进阶的开发者，希望你都能有所收获！

文章目录

RabbitMQ - SpringCloud 集成 RabbitMQ：微服务场景实践 🐰☁️

在现代微服务架构中，异步通信和解耦是提升系统弹性、可扩展性和响应能力的关键手段。RabbitMQ 作为一款成熟、稳定且功能丰富的消息中间件，凭借其高可用性、灵活的路由机制和强大的社区支持，成为众多企业构建分布式系统的首选。而 Spring Cloud 生态则为 Java 开发者提供了构建微服务应用的一站式解决方案。

将 RabbitMQ 与 Spring Cloud 深度集成，不仅能极大地简化开发流程，还能利用 Spring Boot 的自动配置和 Spring Cloud Stream 的声明式编程模型，让开发者专注于业务逻辑本身，而非底层的通信细节。本文将深入探讨如何在 Spring Cloud 微服务架构中高效、安全地集成 RabbitMQ，并通过一系列贴近实战的代码示例，展示其在订单处理、日志收集、事件驱动等典型场景下的强大威力。

1. 核心概念与优势 🧠

1.1 为什么选择 RabbitMQ？

RabbitMQ 是一个开源的消息代理（Message Broker）和队列服务器，它实现了高级消息队列协议（AMQP）。它的核心优势在于：

  • 解耦：生产者和消费者无需知道对方的存在，只需通过交换机（Exchange）和队列（Queue）进行通信。
  • 异步处理：耗时操作可以放入消息队列，由后台服务异步处理，从而提升前端响应速度。
  • 流量削峰：在高并发场景下，消息队列可以作为缓冲区，平滑处理突发流量，保护后端服务不被压垮。
  • 可靠性：通过消息持久化、发布确认（Publisher Confirm）和消费者手动确认（Manual Ack）等机制，确保消息不丢失。
  • 灵活性：支持多种消息路由模式（Direct, Fanout, Topic, Headers），满足不同业务需求。

1.2 Spring Cloud Stream 的角色

Spring Cloud Stream 是一个用于构建消息驱动微服务的框架。它在 RabbitMQ（或其他消息中间件如 Kafka）之上提供了一层抽象，使得开发者可以通过简单的注解和配置来定义输入（Input）和输出（Output）通道（Binding），而无需关心底层的具体实现。

这种“绑定器”（Binder）模式带来了巨大的好处：

  • 代码解耦：业务代码与具体的消息中间件解耦，未来可以轻松切换到 Kafka 等其他中间件。
  • 开发效率：通过 @Input 和 @Output 注解，几行代码就能完成消息的收发。
  • 统一模型：为不同的消息中间件提供了统一的编程模型。
官方文档是学习 Spring Cloud Stream 的最佳起点，你可以在这里找到详细的配置选项和概念解释：Spring Cloud Stream 官方文档

2. 环境搭建与基础配置 ⚙️

在开始编码之前，我们需要准备好运行环境。

2.1 启动 RabbitMQ 服务

最简单的方式是使用 Docker。如果你的机器上已经安装了 Docker，只需运行以下命令：

docker run -d--name rabbitmq -p5672:5672 -p15672:15672 rabbitmq:3-management

这条命令会启动一个带有管理插件的 RabbitMQ 容器。其中：

  • 5672 是 AMQP 协议的默认端口，供应用程序连接。
  • 15672 是管理界面的 Web 端口，你可以通过浏览器访问 http://localhost:15672，使用默认账号 guest/guest 登录。

2.2 创建 Spring Boot 项目

我们将创建两个微服务：order-service（订单服务）和 inventory-service（库存服务）。order-service 在创建订单后，会向 RabbitMQ 发送一条“扣减库存”的消息，inventory-service 则负责监听该消息并执行实际的库存扣减操作。

首先，使用 Spring Initializr 创建两个项目，确保勾选以下依赖：

  • Spring Web
  • Spring for RabbitMQ (这会自动引入 spring-boot-starter-amqp)
  • Spring Cloud Stream
  • RabbitMQ Binder (对于 Spring Cloud Stream)

或者，在 pom.xml 中手动添加关键依赖：

<!-- Spring Boot Starter AMQP --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-amqp</artifactId></dependency><!-- Spring Cloud Stream --><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-stream-rabbit</artifactId></dependency>

同时，不要忘记在 application.yml 中配置 RabbitMQ 的连接信息：

spring:rabbitmq:host: localhost port:5672username: guest password: guest virtual-host: /

2.3 基础消息收发：使用 Spring AMQP

虽然 Spring Cloud Stream 提供了更高层次的抽象，但理解底层的 Spring AMQP 仍然非常重要。我们先从最基础的 RabbitTemplate 和 @RabbitListener 开始。

2.3.1 发送消息 (order-service)

在 order-service 中，我们可以直接注入 RabbitTemplate 来发送消息。

// OrderService.java@ServicepublicclassOrderService{@AutowiredprivateRabbitTemplate rabbitTemplate;publicvoidcreateOrder(String orderId,String productId,int quantity){// 1. 保存订单到数据库（省略）System.out.println("订单 "+ orderId +" 已创建");// 2. 构建消息体InventoryDeductionRequest request =newInventoryDeductionRequest(productId, quantity);// 3. 发送消息到指定的交换机和路由键 rabbitTemplate.convertAndSend("inventory.exchange","deduct.inventory", request);}}

这里，InventoryDeductionRequest 是一个简单的 POJO，用于封装消息内容。

// InventoryDeductionRequest.javapublicclassInventoryDeductionRequest{privateString productId;privateint quantity;// 构造函数、getter、setter 省略}
2.3.2 接收消息 (inventory-service)

在 inventory-service 中，我们使用 @RabbitListener 注解来监听特定的队列。

// InventoryService.java@ServicepublicclassInventoryService{@RabbitListener(queues ="inventory.deduction.queue")publicvoidhandleInventoryDeduction(InventoryDeductionRequest request){// 执行扣减库存的业务逻辑System.out.println("收到扣减库存请求: "+ request.getProductId()+", 数量: "+ request.getQuantity());// ... 实际的库存扣减操作}}

但是，仅仅这样还不够。我们需要告诉 RabbitMQ 如何将交换机、队列和路由键关联起来。这通常通过配置类来完成。

// RabbitMQConfig.java@ConfigurationpublicclassRabbitMQConfig{// 定义交换机@BeanpublicDirectExchangeinventoryExchange(){returnnewDirectExchange("inventory.exchange");}// 定义队列@BeanpublicQueueinventoryDeductionQueue(){returnnewQueue("inventory.deduction.queue",true);// true 表示队列持久化}// 绑定队列到交换机@BeanpublicBindingbinding(Queue inventoryDeductionQueue,DirectExchange inventoryExchange){returnBindingBuilder.bind(inventoryDeductionQueue).to(inventoryExchange).with("deduct.inventory");}}

这个配置类完成了以下工作：

  1. 声明了一个名为 inventory.exchange 的 Direct 类型交换机。
  2. 声明了一个名为 inventory.deduction.queue 的持久化队列。
  3. 将队列绑定到交换机，并指定路由键为 deduct.inventory。

现在，当 order-service 发送消息到 inventory.exchange 并指定路由键 deduct.inventory 时，消息就会被路由到 inventory.deduction.queue，进而被 inventory-service 的监听器消费。

下面是一个简单的序列图，展示了上述流程：

InventoryServiceRabbitMQOrderServiceUserInventoryServiceRabbitMQOrderServiceUser创建订单保存订单发送“扣减库存”消息转发消息执行库存扣减ACK确认返回订单创建成功

3. 使用 Spring Cloud Stream 进行声明式编程 ✨

虽然 Spring AMQP 功能强大，但在微服务架构中，我们更倾向于使用 Spring Cloud Stream 来进一步简化代码，并获得与中间件解耦的好处。

3.1 定义 Binding 接口

Spring Cloud Stream 的核心是定义 interface，其中包含 @Input 和 @Output 注解的方法。

// InventoryBinding.javapublicinterfaceInventoryBinding{StringINVENTORY_DEDUCTION_OUTPUT="inventoryDeductionOutput";StringINVENTORY_DEDUCTION_INPUT="inventoryDeductionInput";@Output(INVENTORY_DEDUCTION_OUTPUT)MessageChannelinventoryDeductionOutput();@Input(INVENTORY_DEDUCTION_INPUT)SubscribableChannelinventoryDeductionInput();}

这里我们定义了两个通道：一个用于输出（发送）消息，一个用于输入（接收）消息。

3.2 在生产者中发送消息 (order-service)

首先，在 order-service 的主启动类上启用绑定：

// OrderApplication.java@SpringBootApplication@EnableBinding(InventoryBinding.class)// 启用我们定义的BindingpublicclassOrderApplication{publicstaticvoidmain(String[] args){SpringApplication.run(OrderApplication.class, args);}}

然后，修改 OrderService，使用 MessageChannel 来发送消息：

// OrderService.java@ServicepublicclassOrderService{@Autowired@Output(InventoryBinding.INVENTORY_DEDUCTION_OUTPUT)privateMessageChannel inventoryDeductionOutput;publicvoidcreateOrder(String orderId,String productId,int quantity){System.out.println("订单 "+ orderId +" 已创建");InventoryDeductionRequest request =newInventoryDeductionRequest(productId, quantity);// 构建Message并发送 inventoryDeductionOutput.send(MessageBuilder.withPayload(request).build());}}

3.3 在消费者中接收消息 (inventory-service)

同样，在 inventory-service 的主启动类上启用绑定：

// InventoryApplication.java@SpringBootApplication@EnableBinding(InventoryBinding.class)publicclassInventoryApplication{publicstaticvoidmain(String[] args){SpringApplication.run(InventoryApplication.class, args);}}

然后，使用 @StreamListener 注解来监听消息：

// InventoryService.java@ServicepublicclassInventoryService{@StreamListener(InventoryBinding.INVENTORY_DEDUCTION_INPUT)publicvoidhandleInventoryDeduction(InventoryDeductionRequest request){System.out.println("收到扣减库存请求: "+ request.getProductId()+", 数量: "+ request.getQuantity());// ... 实际的库存扣减操作}}

3.4 配置 Binding

最后，我们需要在 application.yml 中配置这些通道如何与 RabbitMQ 的实体（交换机、队列）进行映射。

# order-service 的 application.ymlspring:cloud:stream:bindings:inventoryDeductionOutput:destination: inventory.deduction.exchange # 对应RabbitMQ的交换机content-type: application/json rabbit:bindings:inventoryDeductionOutput:producer:exchangeType: direct routingKeyExpression: '''deduct.inventory''' # 固定路由键
# inventory-service 的 application.ymlspring:cloud:stream:bindings:inventoryDeductionInput:destination: inventory.deduction.exchange group: inventory-service-group # 消费者组，用于保证消息只被一个实例消费content-type: application/json rabbit:bindings:inventoryDeductionInput:consumer:bindingRoutingKey:'deduct.inventory'# 监听的路由键

通过这种方式，我们完全将业务逻辑与 RabbitMQ 的具体配置分离。如果将来要迁移到 Kafka，只需要更改 pom.xml 中的依赖和 application.yml 中的 binder 配置，而 OrderService 和 InventoryService 的代码几乎不需要改动。

4. 高级特性与最佳实践 🛡️

在生产环境中，仅仅能收发消息是远远不够的。我们需要考虑消息的可靠性、错误处理、性能优化等一系列问题。

4.1 消息可靠性保证

消息丢失是分布式系统中最令人头疼的问题之一。为了保证消息的可靠传递，我们需要从生产者和消费者两端入手。

4.1.1 生产者端：发布确认（Publisher Confirm）

RabbitMQ 支持发布确认模式。当消息被成功投递到所有匹配的队列后，Broker 会向生产者发送一个确认（ack）。

在 Spring Boot 中，可以通过配置开启：

spring:rabbitmq:publisher-confirm-type: correlated # 开启发布确认publisher-returns:true# 开启失败返回

然后，我们可以为 RabbitTemplate 设置回调，以处理成功或失败的情况。

// 在配置类中@BeanpublicRabbitTemplaterabbitTemplate(ConnectionFactory connectionFactory){RabbitTemplate template =newRabbitTemplate(connectionFactory); template.setConfirmCallback((correlationData, ack, cause)->{if(ack){System.out.println("消息成功投递到Broker");}else{System.err.println("消息投递失败: "+ cause);// 这里可以将消息存入数据库，进行重试}}); template.setReturnsCallback(returned ->{System.err.println("消息无法路由到任何队列: "+ returned.getMessage());});return template;}
4.1.2 消费者端：手动确认（Manual Ack）

默认情况下，Spring AMQP 使用自动确认模式（autoAck）。这意味着一旦消息被消费者方法接收，RabbitMQ 就会认为消息已被成功处理并将其从队列中删除。如果此时消费者在处理过程中崩溃，消息就会永久丢失。

为了避免这种情况，我们应该使用手动确认模式。

# inventory-service 的 application.ymlspring:rabbitmq:listener:simple:acknowledge-mode: manual # 手动确认

然后，在消费者代码中，我们需要显式地调用 channel.basicAck() 或 channel.basicNack()。

@RabbitListener(queues ="inventory.deduction.queue")publicvoidhandleInventoryDeduction(InventoryDeductionRequest request,Channel channel,@Header(AmqpHeaders.DELIVERY_TAG)long deliveryTag){try{// 执行业务逻辑// ... 扣减库存 channel.basicAck(deliveryTag,false);// 手动ACK}catch(Exception e){// 处理异常try{// 第三个参数requeue决定是否重新入队// 如果是业务异常，可能不应该重试，而是进入死信队列 channel.basicNack(deliveryTag,false,false);}catch(IOException ioException){ ioException.printStackTrace();}}}

4.2 死信队列（DLQ）与错误处理

即使有完善的异常处理，某些消息可能因为数据格式错误或业务规则限制而永远无法被成功处理。如果一直重试，会阻塞整个队列。这时，死信队列（Dead Letter Queue, DLQ）就派上用场了。

我们可以配置一个普通队列，当消息被拒绝（Nack）或过期（TTL）时，自动将其路由到一个专门的 DLQ 中，供后续人工排查或自动修复。

// RabbitMQConfig.java@ConfigurationpublicclassRabbitMQConfig{// 死信交换机@BeanpublicDirectExchangedeadLetterExchange(){returnnewDirectExchange("dlx.exchange");}// 死信队列@BeanpublicQueuedeadLetterQueue(){returnQueueBuilder.durable("dlq.inventory.deduction").build();}// 绑定死信队列@BeanpublicBindingdlqBinding(){returnBindingBuilder.bind(deadLetterQueue()).to(deadLetterExchange()).with("dlq.inventory.deduction");}// 主队列，配置死信参数@BeanpublicQueueinventoryDeductionQueue(){returnQueueBuilder.durable("inventory.deduction.queue").withArgument("x-dead-letter-exchange","dlx.exchange").withArgument("x-dead-letter-routing-key","dlq.inventory.deduction").build();}// ... 其他绑定}

这样，当 inventory.deduction.queue 中的消息被 basicNack 且 requeue=false 时，它就会被自动发送到 dlq.inventory.deduction 队列中。

4.3 消息幂等性

在网络不稳定的情况下，可能会出现消息重复投递的问题。因此，消费者的业务逻辑必须是幂等的，即对同一条消息执行多次，结果与执行一次相同。

实现幂等性的常见方法是在数据库中记录已处理的消息ID（Message ID）。在处理消息前，先检查该ID是否已存在。

@RabbitListener(queues ="inventory.deduction.queue")publicvoidhandleInventoryDeduction(InventoryDeductionRequest request,@Header("spring_returned_message_correlation")String messageId,Channel channel,@Header(AmqpHeaders.DELIVERY_TAG)long deliveryTag){if(messageId ==null){// 如果没有Message ID，可以根据业务生成一个，例如 orderId+productId messageId =generateMessageId(request);}if(isMessageProcessed(messageId)){// 消息已处理，直接ACK channel.basicAck(deliveryTag,false);return;}try{// 执行业务逻辑deductInventory(request);// 记录消息IDrecordProcessedMessage(messageId); channel.basicAck(deliveryTag,false);}catch(Exception e){ channel.basicNack(deliveryTag,false,true);// 重新入队，稍后重试}}

4.4 性能与监控

对于高吞吐量的场景，可以调整消费者的并发数。

spring:rabbitmq:listener:simple:concurrency:5# 最小并发消费者数max-concurrency:10# 最大并发消费者数

此外，RabbitMQ 自带的管理界面（http://localhost:15672）提供了丰富的监控指标，如队列长度、消息速率、消费者数量等。你也可以集成 Micrometer，将 RabbitMQ 的指标暴露给 Prometheus 等监控系统。

5. 微服务场景实战案例 💼

理论知识需要通过实践来巩固。下面我们来看几个典型的微服务集成场景。

5.1 场景一：订单创建与库存扣减（已完成）

这是我们贯穿全文的基础案例，它完美地展示了服务间的解耦和异步通信。

5.2 场景二：用户注册与欢迎邮件发送

当用户在 user-service 中注册成功后，系统需要异步发送一封欢迎邮件。邮件服务 email-service 应该独立于用户服务，即使邮件服务暂时不可用，也不应影响用户注册流程。

消息模型:

publicclassWelcomeEmailEvent{privateString email;privateString username;// ...}

user-service 发送消息:

@ServicepublicclassUserService{@Autowired@Output("welcomeEmailOutput")privateMessageChannel welcomeEmailOutput;publicvoidregisterUser(User user){// 1. 保存用户 userRepository.save(user);// 2. 发送欢迎邮件事件WelcomeEmailEvent event =newWelcomeEmailEvent(user.getEmail(), user.getUsername()); welcomeEmailOutput.send(MessageBuilder.withPayload(event).build());}}

email-service 接收消息:

@ServicepublicclassEmailService{@StreamListener("welcomeEmailInput")publicvoidsendWelcomeEmail(WelcomeEmailEvent event){// 调用邮件API发送邮件 mailClient.send(event.getEmail(),"Welcome!","Hello "+ event.getUsername()+"!");}}

这种模式非常适用于非核心、耗时的下游操作。

5.3 场景三：分布式事务与最终一致性

在微服务架构中，跨服务的数据一致性是一个难题。传统的两阶段提交（2PC）性能差且复杂。一种更实用的方案是基于消息队列的最终一致性。

假设我们的订单服务和账户服务是分开的。创建订单时，需要同时扣减用户的账户余额。

流程:

  1. order-service 开启本地事务，创建订单（状态为“待支付”），并向 account-service 发送“预扣款”消息。
  2. account-service 收到消息，执行预扣款（冻结资金），并发送“预扣款成功”消息回 order-service。
  3. order-service 收到确认后，将订单状态更新为“已支付”。

如果任何一个环节失败，都有相应的补偿机制（如取消订单、解冻资金）。

这个流程可以用一个状态图来表示：

发送预扣款消息

收到预扣款成功

预扣款失败/超时

OrderCreated

AccountDeducting

OrderPaid

OrderCancelled

这种模式虽然不能保证强一致性，但能保证在一定时间内达到最终一致，并且具有很高的可用性和伸缩性。

5.4 场景四：日志收集与分析

在微服务架构中，日志分散在各个服务节点上，排查问题非常困难。我们可以利用 RabbitMQ 作为日志的传输管道，将所有服务的日志统一发送到一个中央日志服务，再由其转发给 ELK（Elasticsearch, Logstash, Kibana）或类似系统进行存储和分析。

每个微服务可以配置一个 LogAppender，将日志事件发送到 RabbitMQ。

// 在 logback-spring.xml 中<appender name="RABBIT"class="org.springframework.amqp.rabbit.logback.AmqpAppender"><host>localhost</host><port>5672</port><username>guest</username><password>guest</password><exchange>logs</exchange><declareExchange>true</declareExchange><routingKeyPattern>log.%level</routingKeyPattern><generateId>true</generateId><charset>UTF-8</charset><durable>false</durable><deliveryMode>NON_PERSISTENT</deliveryMode></appender>

中央日志服务只需监听 logs 交换机，即可收集所有日志。

6. 常见问题与排查技巧 🕵️‍♂️

6.1 消息未被消费

  • 检查队列是否被正确绑定：登录 RabbitMQ 管理界面，查看队列的绑定关系是否符合预期。
  • 检查消费者是否在线：确认 inventory-service 是否已成功启动，并且没有报错。
  • 检查消息的路由键：确保生产者发送消息时使用的路由键与消费者监听的路由键匹配。

6.2 消息重复消费

  • 确认是否开启了手动ACK：自动ACK模式下，如果消费者在处理完消息前崩溃，消息会重新入队。
  • 检查业务逻辑是否幂等：这是应对重复消息的根本方法。

6.3 性能瓶颈

  • 增加消费者并发数：通过 concurrency 配置。
  • 批量消费：RabbitMQ 支持批量获取消息，但 Spring AMQP 默认不开启。可以考虑使用 SimpleRabbitListenerContainerFactory 进行配置。
  • 优化消息体大小：避免在消息中传递大量数据，可以只传递ID，由消费者再去查询数据库。

6.4 连接问题

  • 检查网络和防火墙：确保应用服务器可以访问 RabbitMQ 的 5672 端口。
  • 检查凭证：确认 application.yml 中的用户名和密码正确。
  • 查看 RabbitMQ 日志：通常位于 /var/log/rabbitmq/ 目录下，可以提供详细的错误信息。

7. 总结与展望 🌈

通过本文的详细讲解和代码示例，我们系统地学习了如何在 Spring Cloud 微服务架构中集成 RabbitMQ。从最基础的环境搭建、消息收发，到使用 Spring Cloud Stream 进行声明式编程，再到生产环境中的可靠性、幂等性、错误处理等高级话题，我们覆盖了微服务消息通信的方方面面。

RabbitMQ 与 Spring Cloud 的结合，为构建健壮、可扩展的分布式系统提供了强大的支撑。它不仅解决了服务间同步调用的痛点，还为实现事件驱动架构（Event-Driven Architecture）奠定了坚实的基础。

未来，随着云原生技术的发展，像 RabbitMQ 这样的传统消息中间件也在不断演进。例如，RabbitMQ 的 Streams 插件提供了类似 Kafka 的日志结构，更适合处理海量数据流。同时，Spring Cloud Stream 也在持续更新，以更好地支持函数式编程模型（java.util.function）。

无论技术如何变化，解耦、异步、可靠的核心思想始终不变。掌握好这些原则，并结合具体的工具和框架，你就能在复杂的微服务世界中游刃有余。

希望这篇博客能成为你微服务之旅中的一盏明灯。Happy Coding! 💻🚀

🙌 感谢你读到这里！
🔍 技术之路没有捷径，但每一次阅读、思考和实践，都在悄悄拉近你与目标的距离。
💡 如果本文对你有帮助，不妨 👍 点赞、📌 收藏、📤 分享 给更多需要的朋友！
💬 欢迎在评论区留下你的想法、疑问或建议，我会一一回复，我们一起交流、共同成长 🌿
🔔 关注我，不错过下一篇干货！我们下期再见！✨

Read more

Ubuntu新手必看：如何快速更换国内源（阿里/清华/中科大源对比）

Ubuntu 新手的第一道“加速”关：国内镜像源深度解析与实战指南 刚装好 Ubuntu，那种清爽的桌面和开箱即用的感觉确实不错。但当你兴冲冲地打开终端，准备用 apt install 装点东西时，进度条那慢如蜗牛的爬行速度，是不是瞬间浇灭了一半的热情？别急着怀疑自己的网络，这几乎是每个国内 Ubuntu 用户都会遇到的“新手墙”。问题的核心，往往不在于你的宽带，而在于系统默认连接的软件仓库服务器远在海外，网络延迟和带宽限制成了最大的瓶颈。 解决这个问题的方法，就是“换源”——将系统的软件源地址，更换为位于国内的镜像服务器。这听起来像是个简单的操作，但背后其实有不少门道：国内有哪些可靠的镜像站？阿里云、清华大学、中国科学技术大学（USTC）的源有什么区别？为什么别人的源换上去飞快，你的却报了一堆错？今天，我们就来彻底拆解这个问题。这不仅仅是复制粘贴几行命令，而是帮你理解原理、掌握选择、并能在遇到问题时自己动手排查。无论你是刚接触 Linux 的开发新手，还是希望优化工作流效率的资深用户，一个配置得当的软件源，

By Ne0inhk
玩转ClaudeCode：ClaudeCode安装教程（Windows+Linux+MacOS）

玩转ClaudeCode：ClaudeCode安装教程（Windows+Linux+MacOS）

本文介绍如何安装 AI 编码界一骑绝尘的最强工具 ——— Claude Code。安装不同的操作系统环境，本文会从 Windows、Linux、Mac 三个不同的系统环境依次介绍安装方法。 其中，Windows 系统作为大家最主流的操作系统，提供了两种安装方式，一种方式是直接在 Windows 的终端里安装，另一种是在 Windows 的子系统（WSL）内完成安装。其中，通过 WSL 安装，我们又可以分为，WSL 环境的直装和基于 WSL 的容器化安装（Docker），几种方法各有利弊，但均可正常使用。 Windows 环境直装 Claude Code 1. 获取 Claude Code 账号 访问 Claude Code 中国镜像站，完成账户注册。 输入邀请码

By Ne0inhk
Flutter 三方库 swagger_parser 自动化打通鸿蒙 API 通信（一键将 Swagger 转化为 Dart 模型）

Flutter 三方库 swagger_parser 自动化打通鸿蒙 API 通信（一键将 Swagger 转化为 Dart 模型）

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net 前言 在进行 OpenHarmony 项目开发时，最枯燥的工作莫过于根据后端提供的 Swagger (OpenAPI) 文档手动编写一个个的 Request 类、Response 类和 API Client。这不仅低效，而且极易因文档更新没对齐而导致 Bug。 swagger_parser 是一个强大的命令行工具，它能直接读取本地或网络上的 Swagger JSON/YAML 文件，自动为你生成完整的 Dart 数据类和 Dio/Chopper API 控制器。 一、核心工作流 Swagger JSON / YAML Swagger Parser Dart 数据模型 (JSON Serialized) Dio / Chopper

By Ne0inhk
0x80070035找不到网络路径怎么办？win10/win11的6种有效解决方法

0x80070035找不到网络路径怎么办？win10/win11的6种有效解决方法

在win10或win11电脑访问局域网共享文件、连接其他设备时，不少人会遇到 “0x80070035 找不到网络路径” 报错，导致无法读取共享数据、协作受阻。据某技术社区2025年用户反馈统计，该错误在局域网场景占比超65%。下面我们将深入分析这一问题，并提供多种经过验证的解决方案。 一、0x80070035错误是什么 0x80070035是Windows系统访问网络资源时常见的错误代码，意味着系统无法定位到指定的网络路。当用户尝试访问局域网中的另一台计算机的共享文件夹或打印机时，系统会尝试通过网络路径（如\计算机名\共享名）建立连接，而这一过程因各种原因可能中断。这一错误在Windows 7、Windows 10和Windows 11系统中均有出现，成因多样但解决方案相似。 二、为什么会出现0x80070035错误？ 0x80070035错误的产生涉及多个层面的因素，主要可归纳为以下四类： 1️⃣网络配置问题：网络发现功能未启用是最常见的原因之一。同一局域网内的计算机若想相互访问，必须确保所有设备开启了网络发现和文件共享功能。 2️⃣服务运行异常：多个Windows服

By Ne0inhk