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
asyncio重构Flask接口：QPS从300到1800的并发优化实录
一个内部报表接口因串行调用3次第三方服务，平均耗时2.8秒，压测QPS仅320。用asyncio+httpx将其改造为并发请求后，接口耗时降至0.6秒，QPS飙升至1750。本文记录完整改造流程，包括asyncio.Semaphore限流、httpx.AsyncClient连接池复用、以及Python 3.10+的TaskGroup写法，并附上wrk压测对比数据。踩坑部分重点分析了协程与线程混用导
7B模型LoRA微调实录：显存9.3G吞吐提升3.1倍的调参全流程
在单卡A100(80G)上对Llama-2-7B-Chat进行LoRA微调，采用peft 0.5.0+transformers 4.36.2，rank=8时训练显存仅9.3GB，相比全参微调降低72.6%。通过构造中文医疗指令集3.2万条，训练3个epoch后，模型在CMB医学问答基准上BLEU从5.2提升至12.8，F1从0.31升至0.61。本文记录从数据清洗到推理部署的完整链路，包含三个关键
Docker Compose编排多服务容器化部署：网络、卷挂载与健康检查全解析
本文基于Docker Compose 2.24.0，详细拆解一个包含Nginx、Spring Boot后端、PostgreSQL、Redis四服务的生产级编排方案。重点演示自定义Bridge网络隔离、命名卷持久化、依赖健康检查（healthcheck + depends_on.condition）以及启动顺序控制。通过实际压测数据：服务启动时间从串行的47秒缩短至23秒，容器重启故障恢复时间控制在
React 18与Vue 3告别Props钻透：Zustand与Pinia迁移实录
项目从React 16升级到React 18，同时Vue 2老项目重构为Vue 3，两者都面临组件层级深、Props/Context传递混乱导致的重复渲染问题。本文记录了分别迁移到Zustand 4.4.7和Pinia 2.1.7的完整过程。通过对比Context/Props与状态管理库的性能差异，用Lighthouse和React Profiler数据说明：迁移后首屏渲染时间平均减少23%，交互
Prompt Engineering实验对比：从5.2%到68.4%的准确率跃升
同一文本分类任务，使用零样本、少样本、思维链与自我一致性四种Prompt方案，在GPT-4o-mini上准确率从5.2%提升至68.4%，单次推理token消耗从312增至1867。本文记录完整实验过程，包含Prompt模板、OpenAI SDK调用代码、成本核算与失败案例分析，证明结构化Prompt对输出质量的杠杆效应远大于模型微调。
用asyncio将Flask API吞吐量提升3倍：协程改造实践与坑点解析
一个基于Flask 2.2.3 + Gunicorn 20.1.0的订单查询接口，在QPS 500时P99延迟飙到800ms，CPU利用率只有30%。通过asyncio 3.10.7配合`async/await`重构IO密集路径，并引入`asyncio.Queue`做限流，最终在相同硬件下QPS提升至1500，P99降到210ms。本文记录完整的改造过程，包含before/after代码、压测数据
7B模型LoRA/QLoRA微调实录：显存从24G降到6G，效果却提升了3.2%
本文记录了一次完整的LLM微调实践，使用LoRA和QLoRA技术对Qwen2.5-7B-Instruct模型进行领域适应训练。在单张RTX 3090（24GB）上，通过QLoRA将显存占用从全参微调的23.5G降至6.1G，训练速度仅下降18%。微调后的模型在代码生成任务上BLEU分数提升3.2%，在特定领域问答准确率从68.4%提升至91.7%。文中详细展示了数据准备、bitsandbytes
Milvus与Qdrant选型实测：千万级向量下的部署与延迟对比
在内容审核场景中，我们需对每日新增的200万条文本向量进行近实时检索。本文基于Milvus 2.4.5与Qdrant 1.9.7，在相同的16C32G裸金属环境下完成部署，并使用500万条768维向量（SGPT-125M生成）进行压测。实测结果显示：Qdrant在P99查询延迟上比Milvus低38%（23ms vs 37ms），但Milvus在批量写入吞吐上反超42%（8.2k QPS vs 4
FastAPI性能调优实录：Profiling定位+SQL优化+Redis缓存，接口从2.1s降到180ms
一个订单查询接口，压测P95延迟2.1秒，QPS仅230。通过cProfile定位到90%时间耗在N+1查询和JSON序列化，用SQLAlchemy 2.0的selectinload重写查询，配合Redis 7缓存热点数据，最终P95降到180ms，QPS提升到2100。本文记录完整的调优链路，包含工具用法、代码改动和压测数据对比，不吹不黑，全是实操。
asyncio重构Flask接口，QPS从120飙到980的完整记录
一个内部报表接口，单次查询需聚合5张表数据，平均响应时间850ms，压测QPS仅120。我用asyncio+aiomysql重写后，响应时间降到96ms，QPS达到980，数据库连接数从50降到8。本文完整记录了这次优化的全过程：从同步阻塞的痛点分析，到asyncio事件循环设计，再到aiomysql连接池配置，最后还有协程并发数调优的实战踩坑。所有代码和压测数据均来自真实项目，Python 3.
Milvus 2.4 vs Qdrant 1.9图像检索实测：吞吐差42%资源占用翻倍
在商品以图搜图场景下，我用10万张128维特征向量对比了Milvus 2.4.1与Qdrant 1.9.2。部署上Milvus采用Docker Compose（含Etcd、MinIO），Qdrant单容器运行。实测Qdrant的RPS达到2140，而Milvus仅1240，但Milvus在P99延迟上稳定在8ms，Qdrant波动至23ms。内存占用Milvus 3.2GB，Qdrant仅1.1G
7B模型LoRA/QLoRA微调实录：显存从80G降到24G的工程化方案
微调7B模型对很多团队来说是一道坎：单卡A100 80G勉强跑Full Fine-tuning，但多卡并行通信开销大、显存瓶颈明显。我基于Llama-2-7B和ChatGLM3-6B分别做了LoRA与QLoRA微调，最终把单卡显存压到24G内，训练速度稳定在1100 tokens/s（单卡A10），推理效果在领域数据集上逼平全参微调。本文记录完整的工程链路：数据清洗、loRA rank选择、量化配
RAG召回率从63%到89%：chunk重构与混合检索调优实录
上周处理了一个医疗问答RAG系统的召回瓶颈问题，基于BGE-large-zh的向量检索在500条测试集上命中率仅63%，且长尾实体问题严重。通过将固定512字符切块改为按语义段落自适应切块（平均长度降至186字符），并引入BM25+向量混合检索（权重0.3/0.7），最终叠加bge-reranker-base重排（取top20重排至top5），命中率提升至89%，幻觉率下降12%。本文记录了完整的
Git工作流重构记：从分支混乱到CI/CD门禁的30天改造
三个月前，我们团队还在为“提交到master的代码让CI红了三天”而焦头烂额。50人的研发团队，每天平均60次提交，代码合并冲突频发，发布前总要花半天手动处理分支。这篇文章记录了我们如何通过引入Git Flow + Trunk Based的混合模式，配合GitLab CI的自动化门禁，将分支生命周期从平均7天缩短到1.5天，代码评审通过率从68%提升到92%，线上故障率下降40%。全文包含完整的`
RAG准确率从61%到89%：chunk、embedding与rerank全量调优记录
在医疗知识库问答项目中，Naive RAG的答案准确率仅61%，主要问题集中在段落截断导致上下文丢失、embedding模型对专业术语表征不足。本文记录一次完整的RAG系统优化：将固定512字符chunk改为结构感知的递归切分，embedding从bge-large-zh切换至text2vec-large-chinese（微调后），并引入bge-reranker-base做两阶段召回。优化后，在2
