React 19与Vue 3.5下从Props钻取到Zustand/Pinia的迁移实录
在维护一个超300个组件的中后台项目时，Props层层透传和Context频繁重渲染导致首屏交互延迟超800ms，内存占用峰值达180MB。我将核心业务状态从React Context/Props迁移到Zustand v5，同时将Vue子应用从Props/Provide迁移到Pinia v3，对比了两种方案的实现差异。迁移后，React应用交互响应时间降至120ms，Vue应用组件重渲染次数减少6
asyncio重构Flask接口：QPS从120到980的完整记录
一个订单查询接口，平均耗时380ms，QPS 120，压测时CPU闲置但线程池打满。用asyncio+httpx重写后，P95延迟降到89ms，QPS冲到980。本文记录完整重构过程：从Flask同步视图迁移到asyncio原生协程，包含信号量限流、超时控制、连接池复用，以及两个隐蔽的性能坑——EventLoop阻塞和DNS解析阻塞。所有代码和压测数据均来自真实生产环境（Python 3.10.8
asyncio重构Flask接口：QPS从120到2100的并发改造实录
某次压测中，我发现一个基于Flask的订单查询接口在4核8G机器上QPS仅120，CPU利用率不足30%。通过引入asyncio + aiohttp替换requests同步调用，配合semaphore限流和连接池复用，QPS提升至2100，TP99延迟从820ms降至45ms。本文记录了完整的改造过程，包含before/after代码、asyncio.Semaphore、await futures
Milvus与Qdrant选型实测：中文搜索业务下的性能与资源博弈
在电商语义搜索场景下，我们对比了Milvus 2.4.1与Qdrant 1.9.2的部署复杂度、查询延迟与资源占用。实测500万条512维向量，Milvus在16核32G配置下P99延迟为23ms，Qdrant为41ms；但Qdrant内存占用仅为Milvus的58%。本文记录了两者从Docker部署到参数调优的完整过程，包含三次踩坑经历和最终选型结论，为同样纠结于向量库选型的团队提供一份可直接复
Git工作流重构记：从混乱主干到分支策略与CI/CD落地
三个月前，我们的团队还在为“主干提交”引发的冲突焦头烂额：一次上线平均需要2小时手动合并，线上Bug率高达15%。本文记录了我们将Git工作流从“裸奔”升级为“Git Flow + PR Review + Jenkins流水线”的全过程。文中给出了具体的分支命名规范、`.gitignore`与`Jenkinsfile`配置，以及如何通过`git bisect`定位回归。重构后，我们的发布频率从每周
FastAPI性能调优实录：Profiling定位与多级缓存策略
一个线上接口从平均响应1200ms压到180ms，吞吐量提升6.5倍。本文记录一次完整的API性能调优过程。通过cProfile与py-spy定位到瓶颈不在数据库而在序列化与重复查询；随后引入SQLAlchemy 2.0的selectinload预加载、Redis二级缓存以及gzip中间件，最终在wrk压测下（500并发，60秒）P99延迟从2.1s降至320ms。全程基于FastAPI 0.10
Docker Compose编排多服务：网络隔离与健康检查实战配置
本文分享一个真实项目中的docker-compose.yml配置，涵盖3个服务（Nginx网关、Spring Boot应用、PostgreSQL数据库）的完整编排方案。通过自定义bridge网络实现服务隔离，利用volume持久化数据库文件，配置healthcheck保障启动顺序。实测服务启动时间从手动部署的45秒缩短至18秒，容器重启恢复时间控制在5秒内。文中提供可直接运行的配置代码，并详细说明
FastAPI与Flask性能对决：Profiling驱动DB查询与Redis缓存优化实录
在一次电商订单接口压测中，QPS从420惨跌至87，P99延迟飙至3.2秒。本文记录如何利用py-spy、cProfile定位FastAPI与Flask混合架构下的瓶颈——N+1查询与模板渲染阻塞，通过SQLAlchemy懒加载改造、Redis二级缓存及异步化重写，最终QPS稳定在2100，P99降至210ms。全文含完整代码、压测数据与真实踩坑记录，适合遇到性能瓶颈的Python Web开发者。
FastAPI与Flask性能对决：Profile驱动调优从2s到120ms
某次线上服务接口在QPS 300时P99延迟飙升到2.1秒，数据库连接池被打满，CPU却只用了40%。本文记录了一次完整的API性能调优过程，使用cProfile和py-spy定位瓶颈，对比FastAPI(0.100)与Flask(2.3)在异步SQLAlchemy、Redis缓存、连接池复用等场景下的表现。通过将N+1查询合并为JOIN、引入二级缓存、调整gunicorn worker类型，最终
LangChain与AutoGPT双核驱动：手写Agent记忆与循环控制机制
当AutoGPT的无限循环撞上LangChain的工具调用链，一个300行代码的Agent如何做到98.7%的意图识别准确率？本文记录了一次真实开发经历：在Python 3.11 + LangChain 0.1.0环境下，从零实现带短期记忆（BufferWindow）和长期记忆（SQLite向量检索）的Agent循环控制。重点拆解工具描述格式对LLM决策的影响——当工具描述从30字扩写到200字，
LoRA微调7B参数模型显存压测与推理效果对比实践
当业务需要把7B模型适配到特定领域时，全参微调需要近60GB显存，而LoRA只需16GB。本文基于Baichuan2-7B-Chat，使用PEFT+bitsandbytes完成QLoRA微调，在单张RTX 4090上从数据清洗到loss收敛全程记录。实测显存峰值15.7GB，训练3万步后，领域问答准确率从基线41.2%提升至78.6%，而单次推理延迟仅增加3ms。文中会给出可直接复跑的完整代码，并
FastAPI压测1200qps到4800qps：Profiling与缓存三层优化实录
一个内部报表API从1200qps提升至4800qps的完整调优记录。文章基于FastAPI+SQLAlchemy 2.0+Redis 7，通过py-spy和SlowQuery日志定位瓶颈，依次优化了N+1查询、JSON序列化开销和热点数据缓存。附完整代码片段和wrk压测对比数据，展示每个优化步骤的独立收益。适合被API性能困扰、想了解系统化调优方法的开发者。
Prompt模板迭代实录：从27%到91%的JSON抽取准确率提升
在构建非结构化日志解析服务时，我针对OpenAI GPT-4o-mini设计了五版Prompt模板。通过控制变量法对比零样本、少样本与自校正提示词，最终将公司业务日志中关键字段的JSON抽取准确率从27%提升至91%，单次调用Token消耗从1842降至623。本文记录了完整的实验过程、失败教训与优化策略，包含可复现的代码与量化数据。
7B模型LoRA微调实录：显存9.3G跑通中文医疗问答
微调7B大模型不再是A100专属。本文记录在单张RTX 3090（24G）上，用QLoRA对Qwen2-7B-Instruct进行中文医疗意图识别的完整过程。通过4-bit NF4量化，峰值显存仅9.3G；使用28万条病历对话数据，训练3个epoch后，医学问答BLEU提升22.7%，意图分类F1从0.61涨到0.88。文中提供可直接复用的LoRA配置、数据清洗脚本和推理对比样例，并踩平了PEFT
Docker Compose编排多服务容器化部署：健康检查与启动顺序实践
一个典型的Web项目往往包含前端、后端、数据库、缓存、消息队列等多个服务，手动docker run逐个启动不仅繁琐，而且难以管理依赖关系。本文基于Docker Compose 2.24+，分享一个包含Nginx、Spring Boot、PostgreSQL、Redis、RabbitMQ五服务的生产级编排配置，重点解决服务启动顺序、健康检查、数据卷持久化及自定义网络隔离问题。通过healthchec
7B模型单卡LoRA微调全记录：从QLoRA配置到损失收敛与推理对比
上周用一张24G的4090微调Qwen2-7B做电商评论情感分类，采用QLoRA方案（4-bit NF4量化+LoRA rank=64）。训练集2.1万条，batch_size=4，梯度累积8步，学习率2e-4，cosine调度。最终在800步时loss降到0.31，验证集F1从基座的0.72提升到0.91。本文记录完整流程，包括bitsandbytes配置、PEFT参数选择、训练中遇到的loss
向量数据库选型：Milvus 2.4与Qdrant 1.9在RAG场景下的实测对比
在构建一个百万级商品向量检索的RAG系统时，我对比了Milvus 2.4.1与Qdrant 1.9.5。基于Docker Compose部署、HNSW索引、相同数据集与查询负载，实测Qdrant查询P99延迟为8.2ms，比Milvus低19%；但Milvus在批量写入吞吐上领先34%。内存占用方面，Qdrant在8GB堆外内存下稳定运行，而Milvus依赖其Knowhere引擎需12GB。本文记
asyncio重构Flask接口：QPS从120到1800的并发改造实录
上周我负责的订单导出API在高峰期频繁超时，单机QPS只有120，客户端重试率高达15%。排查发现瓶颈是同步请求第三方物流API时线程阻塞。我用asyncio+httpx对核心逻辑做异步化改造，将串行等待改为并发IO，最终单机QPS提升到1800，P99延迟从2.3s降到180ms。本文记录完整改造过程，包括事件循环设计、信号量限流、以及一个坑：Flask与asyncio的兼容性陷阱。版本：Pyt
Prompt工程化实践：从3.2%到41.7%准确率——实体抽取任务的提示词迭代实录
在一次保险理赔实体抽取任务中，我通过四轮Prompt迭代，将GPT-4o-mini的F1分数从3.2%提升至41.7%，同时token消耗降低37%。本文记录了从零样本模板到结构化约束、从单一输出到多轮校验的完整过程，包含温度参数、system prompt分隔符、few-shot样本选择等细节对结果的影响。全文包含2个可复现代码块，所有实验数据基于OpenAI API 2024年8月版本。
Prompt工程化调优实录：从42%到91%的RAG问答准确率跃迁
在构建基于GPT-4的私有知识库问答系统时，我发现默认Prompt的准确率仅有42%，且单次调用消耗高达2800 tokens。经过四轮结构化实验，对比了Zero-shot、Few-shot、Chain-of-Thought及自一致性（Self-Consistency）四种策略，最终确定了一套包含角色约束、格式锚定和推理链的复合Prompt，将准确率提升至91%，同时将平均响应Token消耗稳定控
