FastAPI接口300ms压到38ms：profile、SQL三板斧与Redis缓存实战
一个真实的后台查询接口，P95延迟从312ms降到38ms，吞吐量提升4.6倍。文章记录了完整的调优链路：先用cProfile和py-spy定位CPU热点，发现SQLAlchemy ORM隐式N+1查询和JSON序列化是两大元凶；随后用`explain ANALYZE`重写SQL，引入联合索引与`selectinload`；最后在Redis层做二级缓存，配合`lru_cache`做热点参数缓存。文
asyncio重构Flask API：QPS从37到312的完整改造记录
在一次外部接口压测中，我发现一个基于Flask 2.1 + Requests库的聚合API在50并发下QPS仅37，P99延迟高达4.8秒。通过将阻塞IO替换为asyncio + aiohttp，并在Flask中嵌入asyncio.run，仅改动80行代码，QPS提升至312（8.4倍），P99降至410ms。本博客完整记录这次改造的全部细节：包括事件循环冲突的坑、Semaphore信号量控制并发
RAG召回率从61%到89%：chunk重构与embedding重排的工程实践
在基于LangChain构建的金融文档问答系统中，通过三个阶段的优化——滑动窗口chunk策略替代固定长度切分、bge-large-zh-v1.5替换text2vec-large-chinese、以及引入bge-reranker-base重排序模型，将Top-5召回准确率从61.3%提升至89.7%。本文记录了完整的调优过程，包括向量维度对检索延迟的影响、chunk重叠率与上下文丢失的权衡、以及重
向量数据库选型：Milvus与Qdrant在百万级影视素材检索中的实测对比
在影视素材库的以图搜图业务中，我们对比了Milvus 2.4.1与Qdrant 1.9.2在百万级768维向量下的表现。Qdrant在单机部署上节省了约40%内存，查询P95延迟低至12ms，而Milvus在批量写入吞吐上领先35%。本文记录了两者的Docker部署、Python客户端代码、HNSW参数调优过程，以及一次关于内存溢出的惨痛踩坑经历，希望能为同样在做向量检索选型的朋友提供一份量化参考
Prompt工程化实验：实体抽取任务中5种模板的token与F1权衡
在实体抽取任务中，我对比了5种Prompt模板（零样本、少样本、思维链、结构化输出、角色扮演）在GPT-4-turbo（1106版本）下的表现。实验基于自建的中文金融公告数据集（200条），发现结构化输出模板在F1分数（0.82）与token消耗（平均412 tokens/条）之间取得了最佳平衡。而角色扮演模板虽然F1达到了0.85，但token开销暴涨至687 tokens/条，性价比骤降。文中
asyncio重构Flask接口，QPS从120飙到850的详细记录
一个内部报表API，单次查询需聚合3个微服务数据，平均耗时1.2秒，压测QPS仅120。我用asyncio+httpx将其重构为并发IO后，P95延迟从2.1s降到380ms，QPS稳定在850。本文记录从同步阻塞到异步非阻塞的完整改造过程，包含asyncio.Semaphore限流、超时控制、Python 3.11的asyncio.TaskGroup用法，以及一个差点导致连接池耗尽的坑。
Python asyncio重构Flask接口：耗时从2.3秒降至0.4秒
一个内部报表API，单次请求需聚合三个外部服务数据，平均耗时2.3秒。用asyncio + httpx重写后，耗时降至0.4秒，QPS从45提升到220。本文记录了完整的改造过程，包括event loop线程冲突的坑、信号量限流配置、以及Python 3.11 vs 3.10的性能差异。代码可直接复用到任何IO密集型的Web接口。
FastAPI+SQLAlchemy 2.0 性能调优：从1200ms到80ms的profiling与缓存实践
一个真实的生产环境接口，单次请求耗时1200ms，QPS仅能支撑50。通过py-spy定位到N+1查询与JSON序列化两大瓶颈，配合SQLAlchemy 2.0的selectinload优化和Redis二级缓存，最终将P95延迟压至80ms，QPS提升至800+。本文记录了完整的profiling工具链（py-spy、cProfile、Prometheus）、缓存策略设计（Cache-Aside
Python异步编程：asyncio重构Flask接口吞吐量提升3.2倍
在一次电商大促压测中，我发现某个订单查询接口在QPS达到200时RT飙升至2.8s，而数据库负载却不足30%。通过引入asyncio+httpx将串行RPC调用改为并发协程，接口吞吐量从320 QPS提升至1024 QPS，P99延迟从1.2s降至380ms。本文记录了完整的重构过程，包括asyncio.Semaphore限流、aiohttp连接池调优、以及uvloop替换事件循环的实测数据。踩坑
React 19与Vue 3.5下从Props钻取到Zustand与Pinia的状态重构实录
在维护一个拥有87个路由页面、42个共享业务模块的中后台系统时，props钻取导致的无效渲染让我在Chrome Performance面板里看到了单次交互触发31次组件重渲染的窘境。本文记录了从React 19的Context/Props方案迁移至Zustand v5，以及Vue 3.5项目迁移至Pinia v3的完整过程。包括迁移前后的bundle体积对比（React项目减少18KB，Vue项目
FastAPI接口耗时400ms优化到45ms：Profiling与缓存策略全记录
一个内部报表API在QPS 200时P95延迟飙至380ms，数据库CPU被打满。本文记录了从Profiling定位（cProfile+py-spy）、SQLAlchemy N+1查询治理、多级缓存（Redis+本地Cache）到最终P95降至48ms、CPU占用降72%的完整过程。包含FastAPI 0.115与SQLAlchemy 2.0的实操代码与压测数据对比，踩坑细节同步给出。
Git分支策略与Code Review流水线：支撑百人研发团队的协作体系
当团队从20人扩张到120人，主干开发模式引发的代码冲突、发布事故呈指数级增长。本文基于Git 2.39.1与GitLab 15.11，落地了一套融合Trunk-Based与GitFlow优点的混合分支策略，配合基于Merge Request的强制Code Review流水线（含Prettier、ESLint、Jest自动化门禁），将平均代码评审等待时间从4.2小时降至1.1小时，线上事故率降低7
asyncio重构Flask接口：并发等待减300%，QPS翻4倍全程记录
一个内部报表API，单次请求需聚合4个外部服务数据，平均耗时820ms，高峰期Tomcat线程池被打满。用asyncio + aiohttp重写后，P95延迟从1.2s降到280ms，QPS从120升到480。本文记录完整重构过程：从同步阻塞到事件循环，包含asyncio.Semaphore限流、连接池复用、超时控制三个关键优化点，并给出具体压测数据与Python 3.10下的踩坑解决方案。
FastAPI×Flask双框架API性能调优：cProfile定位与Redis缓存实战
一个生产环境接口从平均响应1800ms压到220ms，P99从4.2s降到380ms，数据库QPS从1200降至150，CPU占用降低40%。本文基于FastAPI(0.104.1)与Flask(3.0.0)双框架对比实验，完整记录了性能瓶颈的定位过程：先用cProfile和py-spy揪出隐藏的N+1查询与序列化开销，再通过SQLAlchemy(2.0.25)的`selectinload`策略和
React 19与Vue 3.5下从Context到Zustand/Pinia的状态重构实录
我的后台管理系统在列表页频繁操作时，Context导致的全局重渲染让性能面板飙红到120ms。本文记录从React 19的Context+useReducer迁移至Zustand 5，以及Vue 3.5的provide/inject迁移至Pinia 3的完整过程。包含两种框架的迁移对照、代码差异、以及迁移后FCP提升42%、交互响应时间从87ms降至23ms的具体优化数据。
asyncio重构Flask API：并发等待缩短至1.2秒，性能提升8倍
一个基于Flask 2.0 + Requests库的聚合API，因串行调用3个上游HTTP服务而达到9.8秒的P95延迟。通过引入asyncio + aiohttp 3.8，将阻塞式IO替换为事件循环驱动的协程，在保持接口签名不变的前提下，将P95延迟降至1.2秒，吞吐量从120 QPS提升至960 QPS。本文记录了从同步到异步的完整改造过程，包括Semaphore限流、超时控制、连接池复用等生
React 19与Vue 3.5下从Props钻取到Zustand/Pinia：迁移实录与性能对比
在支撑日均百万请求的中后台项目中，Props drilling和Context泛滥导致组件重渲染次数激增37%，首屏交互延迟达220ms。本文记录了将React 19.1与Vue 3.5双技术栈项目从原生状态传递迁移至Zustand 5.0与Pinia 3.0的全过程。通过6个关键步骤、3个可运行代码块，对比了迁移前后组件树渲染耗时（由18ms降至6.2ms）、内存占用（下降28%）及代码维护成本
asyncio重构Flask接口：QPS从120到1850的并发优化实录
某次压测发现一个调用第三方REST API的Flask服务，在50并发下QPS仅120，平均延迟420ms，大量请求阻塞在`requests`库的同步IO上。本文通过`asyncio` + `aiohttp` + `uvloop`重构该接口，将同步阻塞改为异步非阻塞，配合`asyncio.Semaphore`控制并发上限，最终QPS提升至1850，P99延迟从800ms降至210ms。文中提供完整
LangChain+AutoGPT思想重构：手写AI Agent核心循环控制机制
当LangChain v0.2.2的AgentExecutor在复杂任务中频繁陷入死循环、记忆混乱时，我决定基于AutoGPT的"计划-执行-反思"范式，从零手写一个仅需287行代码的Agent核心。本文不讨论框架API，而是深入工具注册表设计、滑动窗口记忆管理、异常熔断机制以及最大迭代次数控制。实测在百度百科问答任务中，手写版相比LangChain原生Agent，token消耗减少43%，任务完
FastAPI慢查询优化实录：Profiling定位到缓存设计压测对比
在一次内部服务重构中，我们的FastAPI接口（Python 3.10 + FastAPI 0.95 + SQLAlchemy 2.0）在压测时发现`GET /api/v1/products`接口P99延迟高达2.8秒，TPS仅能维持在180。通过cProfile定位到瓶颈是N+1查询和模板渲染，随后引入`selectinload`批量加载并加了一层Redis缓存，最终P99降至120ms，TPS
