Milvus与Qdrant选型实测：千万级向量下的部署与性能对比
在电商以图搜图业务中，我们需在千万级(10,000,000) 768维向量下实现<100ms查询。本文基于Milvus 2.4.1与Qdrant 1.9.2，在同一台48C/128G物理机上完成部署与压测。结果显示：Qdrant在单机SSD下查询P99为68ms，Milvus为91ms；但Milvus在批量导入(10M向量)耗时仅为Qdrant的62%。内存占用方面，Qdrant吃满27.4G，M
FastAPI性能调优实录：Profiling定位与缓存策略将QPS提升4.7倍
一个用户画像服务接口，上线初期平均响应时间258ms，QPS仅620。通过cProfile定位到SQLAlchemy ORM的N+1查询和模板渲染的重复计算是主要瓶颈。使用`py-spy`进行火焰图分析后，针对性地将热点查询改写为原生SQL并引入Redis缓存热点数据，最终将平均响应时间降至54ms，QPS稳定在2900+。本文记录了完整的调优过程、压测数据与踩坑细节，包含可复现的代码示例。
React/Vue状态管理迁移实录：从Context/Props到Zustand与Pinia的工程化改造
本文记录一次真实的中型后台项目（React 18.2 + Vue 3.4）状态管理重构。项目从混合使用Props透传和Context（React）/Provide（Vue）迁移到Zustand 4.5与Pinia 2.1，核心业务模块渲染耗时降低32%-41%，代码量减少约1200行。文章详细对比两种方案在组件重渲染、调试体验、TypeScript支持上的差异，并给出可执行的渐进式迁移步骤、性能基
Git Flow与Trunk-Based对决：团队协作分支策略及CI/CD落地实践
本文基于3年、50人研发团队的版本控制演进实录，对比了Git Flow与Trunk-Based分支策略在需求并行、紧急修复、版本回溯等真实场景下的优劣。详细展示了基于GitLab Flow的“环境分支+功能开关”混合模型，并给出了完整的`.gitlab-ci.yml`配置与Code Review质量门禁（新增代码测试覆盖率阈值80%）。通过引入自动化合入机器人，将平均发布周期从2天缩短至4小时，代
FastAPI接口性能从1200ms到80ms：Profiling与缓存优化实录
一个内部报表接口在QPS达到50时平均延迟飙升至1200ms，P99直接超过2秒，数据库连接池被打满，CPU居高不下。本文将完整记录我使用Py-Spy、SlowQueryLog定位瓶颈，通过索引优化、Redis缓存和异步改造三步，将接口延迟降至80ms、P95稳定在150ms以内的全过程。文中涉及FastAPI 0.104、SQLAlchemy 2.0、Py-Spy 0.3.14、Redis 7.
LangChain与AutoGPT双核驱动：手写Agent记忆循环与容错机制
当AutoGPT的无限递归让Token消耗飙升至$0.8/次任务失败时，我决定用LangChain重写Agent内核。本文记录了一个生产级Agent的诞生过程：通过Zep开源库实现滑动窗口记忆，使上下文检索准确率从62%提升至91%；引入LangGraph的状态机循环控制，将死循环率降低至0.3%。手写实现工具注册表、异常熔断器与流式输出，最终在MATH-500基准上达到78.4%的准确率，单次任
FastAPI接口延迟飙到2.8秒，我用cProfile和Redis把P95砍到180ms
一个内部数据看板接口，单次请求要聚合7张表的数据，上线后P95延迟高达2.8秒，被业务方连续投诉三天。这篇文章记录了我完整的调优过程：先用cProfile和py-spy定位到瓶颈在N+1查询和JSON序列化，然后通过SQLAlchemy 2.0的selectinload优化查询、引入Redis缓存热点聚合结果、最后用orjson替换标准json库。压测数据从wrk的123 QPS提升到892 QP
Docker Compose编排多服务容器化部署：网络、卷、健康检查与启动顺序
本文分享一个生产级多服务项目的docker-compose.yml配置，涵盖自定义网络、命名卷挂载、依赖健康检查与启动顺序控制，解决服务启动竞态与数据持久化问题。配置基于Docker Compose v2.20+与Docker Engine 24.0，包含PostgreSQL 15、Redis 7、Nginx 1.25及Spring Boot应用四节点编排。通过实际压测数据，展示健康检查将服务可用
RAG召回率从67%到89%：chunk重构与混合检索调优实录
在构建企业知识库问答系统时，我们遭遇了召回质量瓶颈：针对技术文档的复杂查询，基于固定512字符分块的RAG召回率仅67%，且Top-5命中率不足50%。通过将分块策略改为“章节语义边界+重叠窗口”、Embedding模型从BGE-large-zh切换至BGE-M3、并引入Cohere Rerank重排序，最终将召回率提升至89%，Top-5命中率提升至78%。本文将完整记录这一调优过程，附全部核心
RAG命中率从61%到89%：chunk重构与embedding选型全记录
两个月前我们的内部知识库RAG系统还处于“能跑但不可用”的状态——检索命中率仅61%，用户问“发票报销流程”返回的是“差旅费管理制度”。本文记录一次完整的RAG系统优化过程：从vLLM部署的Qwen2.5-7B，到BGE-large-zh-v1.5与text2vec-large-chinese的PK，再到引入bge-reranker-v2-m3。通过重构chunk策略（固定256字符→语义段落），
告别Prop Drilling：React 18与Vue 3项目迁移至Zustand与Pinia的工程化实践
在维护一个超500个组件的中后台项目时，Context/Props层层透传导致重渲染次数激增42%，且新成员接手成本极高。本文记录了我们将React 18项目迁移至Zustand 4.x、Vue 3项目迁移至Pinia 2.x的完整过程。通过对比三种方案的内存占用、渲染性能与代码量，给出了详细的迁移步骤、核心代码示例及性能优化数据。迁移后，React项目首屏渲染时间从2.3s降至1.1s，Vue项
Git分支策略与Code Review流水线：支撑20人团队的协作体系
当团队从5人扩张到20人，主干开发模式导致的代码冲突率飙升300%，发布前集成耗时从30分钟增长到3小时。本文基于Git 2.39.1与GitLab 15.11，落地了一套基于Trunk-based的分支策略，配合强制Code Review与CI/CD流水线。通过引入pre-commit钩子、GitLab CI的merge request pipeline，将平均代码审查周期压缩至4.2小时，线上
LangChain与AutoGPT双引擎：手写AI Agent核心循环的五个关键实现
当AutoGPT的无限循环撞上LangChain的工具调用链，一个能稳定运行200轮不崩的Agent需要怎样的骨架？本文记录了我用LangChain 0.1.0重写AutoGPT核心循环的完整过程。从工具定义到记忆压缩，从异常重试到循环终止条件，手写一个支持Python代码执行、文件搜索、算术计算的Agent。实测单轮工具调用延迟从3.2秒降到1.8秒，内存占用稳定在480MB，连续运行6小时无死
LangChain+AutoGPT思想手写Agent：循环控制与记忆管理全解析
上周在开发一个代码审查助手时，我尝试用LangChain 0.2.1搭建了一个具备AutoGPT风格的Agent，但发现官方AgentExecutor在连续执行超过5轮后内存占用飙升到1.2GB，且工具调用失败时无法自愈。于是我用约300行代码手写了一个轻量Agent，将工具定义抽象为Pydantic模型，用双端队列实现滑动窗口记忆，并引入最大重试次数与错误注入机制。最终在12个真实测试用例上，任
RAG问答延迟降低42%：chunk重构与embedding选型及rerank重排全记录
线上知识库问答系统在2000+文档规模下暴露出召回准确率低、幻觉严重等问题。本文记录了从v1.0到v3.0的三轮优化：将固定256字符chunk改为基于语义边界的动态切片，命中率提升18%；将BGE-small替换为bge-m3，召回Recall@5从68.5%提升至79.2%；最后引入bge-reranker-base重排，Top-1准确率从61%跃升至82%，整体首响延迟仅增加85ms（从68
Docker Compose编排多服务：网络隔离与健康检查的工程实践
本文记录一次真实的多服务容器化部署经历，涉及Nginx、Spring Boot应用、PostgreSQL、Redis共4个服务。通过docker-compose.yml配置，解决服务间网络通信、数据卷持久化、启动顺序依赖三大核心问题。实测部署时间从手工配置的30分钟缩短至2分钟，服务启动失败率降低80%。文中包含完整的compose文件、健康检查配置参数及容器启动顺序验证方案，适合需要快速搭建生产
asyncio重构Flask接口：并发吞吐提升340%的完整记录
一个基于Flask 2.2 + MySQL的订单查询接口，在QPS 120时P99延迟飙到2.8s。改用asyncio + aiomysql + uvloop后，同样的16C16G机器压测，QPS稳定到528，P99降到410ms。本文记录完整重构过程：从同步阻塞的罪魁祸首分析，到asyncio协程改造SQL查询、连接池复用、以及uvloop替换事件循环的取舍。含前置代码、改造后代码、wrk压测数
asyncio重构Flask接口，QPS从120飙到850的全记录
上周我把一个基于Flask的同步商品详情聚合接口改成asyncio协程版，压测结果从120 QPS直接干到850 QPS，P99延迟从2.3s降到380ms。整个过程踩了不少坑——比如asyncio里不小心用了同步requests库导致事件循环卡死，还有aiohttp连接池默认大小不够导致大量TimeoutError。这篇文章会完整记录这次改造的技术方案、核心代码（含before/after）、以
RAG问答延迟砍半：chunk重切+embedding换型+rerank三段式调优实录
线上RAG系统初期Answer Pass Rate仅61%，首Token延迟高达1.8s。本文记录一次完整的检索链路手术：将固定256字chunk改为按Markdown标题自适应切片（平均966字/块），Embedding从text2vec-large-chinese切换至bge-large-zh-v1.5（维度1024，余弦相似度阈值从0.55压到0.42），并在召回Top20后引入bge-re
React 19与Vue 3.5下从Context到Zustand/Pinia的状态迁移实录
在支撑百万级PV的电商后台项目中，Context/Props层层透传导致组件重渲染次数暴增320%，交互延迟突破120ms。本文记录将React 19.1与Vue 3.5混布项目核心模块从Context/Props迁移至Zustand 5.0与Pinia 3.0的全过程，对比三种方案的内存占用（Context：68MB vs Zustand：41MB）、渲染耗时（Props：23.6ms vs P
