weixin_42932609的博客

原创 本地快速运行一个Poetry管理的Python项目

想在本地快速跑一个Poetry管理的Python项目，下面我用一个具体的例子带你一步步操作。我会提供两种常见的初始化方式，并用一个表格对比它们的优缺点和适用场景。⚠️本篇是进阶篇，结合。

原创 Python 中创建虚拟环境的最佳实践方式

venv。

原创 Pipx 和 Poetry 都创建虚拟环境

用途不同用Pipx来安装那些你希望在终端中直接调用的工具poetryblackjupyterhttpie等）。用Poetry来管理你正在开发的项目的依赖和环境。层级关系Pipx 是 “管理工具的工具”。你经常会用 Pipx 安装 Poetry，然后再用 Poetry 去管理你的项目。它们处于不同的层级。结论：它们不是二选一的关系，而是相辅相成、协同工作的现代Python开发最佳实践组合。先用Pipx安装Poetry这个好用的工具，然后再用Poetry去高效地管理你的每一个项目。

原创 LangChain-PromptTemplate和ChatPromptTemplate

是“无角色的纯文本模板”，适合简单文本生成场景；是“带角色的结构化聊天模板”，专为聊天模型设计，能更好地支持系统设定、多轮对话等复杂交互。在实际开发中，对接聊天模型（如 OpenAI 的）时，优先使用，因为它能充分利用模型对角色信息的原生支持，生成更符合预期的响应。

原创 Langchain 之 ChatPromptTemplate.from_template和from_messages 的区别

若你需要创建简单的单轮对话提示，且角色较少（如只有系统消息+用户消息），语法更简洁。若你需要处理多轮对话动态插入历史消息，或涉及复杂角色（如函数调用、消息占位符），是更优选择，因其结构清晰、灵活性更高。实际开发中，因灵活性强，更适合大多数场景，尤其是需要扩展为多轮对话或工具调用的场景。

原创 Langchain 之 ChatPromptTemplate.from_template和from_messages 的区别

若你需要创建简单的单轮对话提示，且角色较少（如只有系统消息+用户消息），语法更简洁。若你需要处理多轮对话动态插入历史消息，或涉及复杂角色（如函数调用、消息占位符），是更优选择，因其结构清晰、灵活性更高。实际开发中，因灵活性强，更适合大多数场景，尤其是需要扩展为多轮对话或工具调用的场景。

原创 单词学习3

（补充高频义项，与第2天“to”区分用法）

原创 LangChain 事件（Event）

本质：事件是 LangChain 提供的“流程节点信号”，让你从“黑盒接收结果”变为“白盒控制过程”；关键场景：交互体验优化、内容安全、性能监控、工具调用；常用事件（开始）、（逐字）、（结束）；使用前提：调用方法时，必须指定（旧版本v1已逐步废弃）。

原创 LangChain 事件在“工具调用”中的简单示例

下面用“让模型调用‘天气查询工具’（模拟工具，无需真实API）”的场景，展示事件如何配合工具调用工作。

原创 Python-传函数本身”还是“传函数调用（函数()）

key=函数本身传「函数本身」（不加括号）传「函数调用（函数()）」（加括号）接收方需要“用这个函数干活”（比如线程执行、排序规则）接收方需要“函数干活后的结果”（比如协程对象、计算结果）函数会在接收方内部被调用（接收方帮你加括号）函数在传递前已经被调用（你自己加括号）典型场景：多线程 target、sort key、回调函数典型场景：asyncio.run、参数传递、结果打印要“工具”传函数本身，要“结果”传函数调用。

原创 LangChain-asyncio异步编程

单个线程，多个任务。任务执行到await（等待 I/O 时）会主动“让权”。事件循环负责切换任务，让线程始终“有事干”。最终效果：不阻塞线程，高效利用时间，看似“同时处理多个任务”。这也是异步比同步（一个任务阻塞就全卡住）高效的原因～

原创 LangChain 链式调用理解

这样就不需要手动先运行榨汁机，再把果汁倒进加冰器，而是一键完成整个流程。（GPT-4翻译） → 得到。（提取纯文本） → 得到。

原创 Prompt Engineering最佳实践

是与AI模型有效沟通的艺术。

原创 单词学习2

aintohave

原创 单词学习1

原创 Python-__name__ == ‘__main__‘

明确指定哪些代码是程序的启动入口。

原创 Python-with与Java 的 try-with-resources

特性Pythonwith目的自动资源管理 + 通用上下文管理自动资源管理语法底层接口__exit__()异常处理需要额外try-except内置异常处理多资源是的，with语句就是 Python 版的 try-with-resources，它们都解决了同样的问题：确保资源被自动、安全地释放，让开发者从繁琐的资源管理代码中解放出来。两者的设计哲学都是：“申请资源，使用资源，自动释放资源”，只是语法实现上有所不同。

原创 Python-with进阶

上下文一个代码执行的环境或状态，在这个环境中需要特定的设置和清理工作。在with资源的获取（进入上下文）资源的使用（执行代码块）资源的释放（退出上下文）上下文在with"一个被明确界定边界的环境，在这个环境内：前期准备工作自动完成你可以安全地执行操作后期清理工作自动保证完成无论操作成功还是失败，开始和结束的流程都得到保障。这就是为什么with语句被称为上下文管理器- 它管理着一个代码执行的完整上下文环境。

原创 Python-with理解

请Python帮我管理这个文件的打开和关闭，我只需要在缩进的代码块中使用文件对象 f 进行操作，完成后你负责帮我妥善关闭文件，即使中间出了错也要保证关闭。这是一种编写更安全、更简洁、更易读代码的最佳实践。

原创 python-`from typing import List`

代码含义适用版本从typing模块导入List工具，用于注解列表的类型（例如List[str]一种导入语法，从typing模块导入你需要的特定类型注解工具。直接使用内置类型list进行泛型注解，表示一个字符串列表。这是现代Python推荐的方式。使用进行泛型注解，效果与list[str]相同。在 3.9 之前是唯一的方式。简单来说，from typing import List就是为了在老版本（3.9之前）的Python中，能够精确地注解列表内部元素类型而进行的一种导入操作。

原创 Spring Cloud Eureka 自我保护机制 vs. Nacos 健康保护机制

【代码】Spring Cloud Eureka 自我保护机制 vs. Nacos 健康保护机制。

原创 Nacos使用的数据库

（Apache Derby），但在生产环境中通常建议。以实现高可用和持久化存储。

原创 Nacos Config 和 Spring Cloud Config 区别

和都是微服务架构中常用的配置中心解决方案，但它们在设计理念、功能和适用场景上有显著区别。

原创 Spring Cloud Sentinel中降级（Fallback）和熔断（Circuit Breaker）

降级（Fallback）和熔断（Circuit Breaker）是微服务容错中两个的概念，它们通常结合使用，但解决的问题和触发机制不同。

原创 Spring Cloud断路器 和 sentinel

Spring Cloud 断路器（Circuit Breaker）并不特指，而是一种通用的容错机制设计模式。在 Spring Cloud 生态中，有多种实现断路器的工具，Sentinel 只是其中之一。

原创 Spring Cloud Sentinel中限流和降级区别

限流是"预防性"的，在系统健康时就开始限制过量请求降级是"补救性"的，在系统出现问题时提供备用方案限流关注"请求数量"，降级关注"请求质量"实际项目中通常需要同时配置限流和降级规则理解这两者的区别对于设计稳定的分布式系统非常重要。限流像是一个"流量阀门"，而降级则像是系统的"安全气囊"，它们从不同角度保护系统的稳定性。

原创 Spring Cloud Sentinel 详解

Sentinel 是阿里巴巴开源的一款轻量级流量控制、熔断降级的 Java 库，特别适合在分布式系统中使用。它是 Spring Cloud 生态中非常重要的组件之一。

原创 奈飞和Netflix 和 Spring Cloud Netflix

奈飞在微服务架构领域是先行者，它开发了Eureka、Ribbon、Feign、Hystrix、Zuul等多个组件用于构建自身的分布式系统，这些组件在微服务的服务发现、负载均衡、远程调用、熔断器、网关等方面发挥了重要作用。后来，Spring Cloud将这些奈飞的组件进行了集成和二次封装，形成了Spring Cloud Netflix项目，开发者通过引入相应的starter，利用少量配置就可以快速在Spring Boot应用中使用这些组件，构建起分布式微服务系统。

原创 Spring Cloud Consul 简介

Spring Cloud Consul 是 Spring Cloud 生态中对 Consul 的适配组件，核心价值是“简化 Consul 在 Spring Cloud 微服务中的使用”，提供服务注册发现和配置管理的一站式解决方案，与 Spring Cloud Netflix、Spring Cloud Alibaba 等属于平行的技术选择，开发者可根据团队技术栈和需求选择合适的方案。

原创 Spring Cloud Netflix 和 Spring Cloud Alibaba

二者均遵循 Spring Cloud 的规范，目标是帮助开发者快速搭建微服务系统，属于“同源（Spring Cloud）不同流（技术栈）”的解决方案。Spring Cloud Netflix 是早期微服务的标杆方案，但随着 Netflix 部分组件停止维护，逐渐被 Spring Cloud Alibaba 等新兴方案替代；Spring Cloud Alibaba 凭借活跃的社区、持续的更新和对国内场景的适配（如阿里云生态），成为当前主流的微服务解决方案之一。

原创 Spring Cloud、Spring Cloud Alibaba、Spring Cloud Alibaba Nacos、Nacos Config 之间的联系与区别

简言之，它们从抽象到具体，层层递进，共同构成了微服务架构中的核心支撑体系。

原创 奈飞 和 Netflix 和 Spring Cloud Netflix

奈飞在微服务架构领域是先行者，它开发了Eureka、Ribbon、Feign、Hystrix、Zuul等多个组件用于构建自身的分布式系统，这些组件在微服务的服务发现、负载均衡、远程调用、熔断器、网关等方面发挥了重要作用。后来，Spring Cloud将这些奈飞的组件进行了集成和二次封装，形成了Spring Cloud Netflix项目，开发者通过引入相应的starter，利用少量配置就可以快速在Spring Boot应用中使用这些组件，构建起分布式微服务系统。

原创 Spring Cloud Bus -8 kafka消息存储

的主题包含3个分区（Partition 0、1、2），消息M1、M2、M3的存储方式取决于生产者使用的分区策略。在Kafka中，名为。

原创 Spring Cloud Bus -7 RabbitMQ 和 kafka 区别二

Kafka 中没有“队列”这一明确概念，但分区（Partition）本质上就是一个实现了 FIFO 的队列，而主题（Topic）则是多个“队列（分区）”的逻辑集合。这种设计让 Kafka 更适合高吞吐量、大规模消息存储的场景（如日志收集、数据同步），通过分区的并行处理提升性能；而传统队列的“队列”概念更直观，适合简单的点对点通信场景。

原创 Spring Cloud Bus -7 RabbitMQ 和 kafka 区别一

Kafka 没有“交换机”概念，其消息路由机制更简洁：通过主题直接接收消息，并基于分区和消费者组实现负载均衡与广播。这种设计让 Kafka 更专注于高吞吐量的日志和消息传输场景，而 RabbitMQ 的交换机机制则更灵活，适合复杂的路由需求。理解这一差异，有助于在实际场景中选择合适的消息队列（如高吞吐选 Kafka，复杂路由选 RabbitMQ）。

原创 Spring Cloud Bus -6 重复消费

在正常情况下，消息一旦被分配给某个消费者，就会与该消费者绑定，其他消费者无法再消费这条消息。只有当消息处理失败并重新入队后，才可能被其他消费者获取，但这属于消息重试机制，而非“跨消费者消费原始分配的消息”。这种机制保证了消息不会被多个消费者重复处理（除非业务允许），是消息队列确保数据一致性的基础设计。

原创 Spring Cloud Bus -5 队列消费顺序

消息队列中的队列默认是先进先出（FIFO）的，这是其核心特性之一，确保了消息的基本顺序性。但在实际使用中，优先级、多消费者并发、重试等机制可能导致“消费完成顺序”与“入队顺序”不一致，不过消息从队列中被取出的顺序始终是FIFO（即队列内部的存储顺序不会乱）。如果业务场景要求“绝对严格的顺序”（如金融交易），可以通过禁用优先级、使用单消费者（避免并发）、关闭重试等方式保障，或选择专门支持强顺序性的消息队列（如Kafka的分区机制，单个分区内严格FIFO）。

原创 Spring Cloud Bus -4 如何消费

消息先存队列：生产者发送的消息先通过交换机路由到具体队列，队列负责暂存消息（持久化确保不丢失）。消费者主动监听：消费者通过长连接监听自己的队列，实时获取新消息。按策略处理：根据业务场景选择“发布-订阅”（多消费者）或“点对点”（单消费者），通过“手动确认”确保消息可靠处理，必要时用“消费者组”实现负载均衡。这种机制既保证了消息能被正确传递到目标服务，又通过队列和确认机制解决了“服务离线时消息暂存”“消息重复消费”等问题，是分布式系统中异步通信的核心保障。

原创 Spring Cloud Bus -3 队列

微服务中的“消息队列”虽然名字包含“队列”，但它是分布式环境下的通信中间件，功能远超过数据结构中的队列：不仅能存储消息，还能实现跨服务的异步通信、消息路由、持久化等，是支撑微服务架构的核心组件之一。简单说：数据结构的队列是“单个程序的工具箱”，而消息队列是“分布式系统的通信枢纽”。

原创 Spring Cloud Bus -2总线

所有微服务通过消息队列连接到同一总线”，本质是通过消息队列的发布-订阅模式，构建一个统一、高效、解耦的分布式事件通信网络。它让微服务之间的协作像“在同一个房间里说话”一样简单，大幅降低了分布式系统的通信复杂度，是 Spring Cloud 生态中实现配置同步、集群通知等场景的核心方案。