相信日志不会说谎，只是有时不够直白。主要研究软件工程与问题排查，记录代码实现与工程实践、架构设计以及那些看似简单却很容易踩坑的问题。记录不一定完美，但力求真实、清楚、可验证。
团队从5人扩展到18人后，直接push到master导致每周平均3.2次线上冲突，回滚耗时从5分钟飙到40分钟。我们最终落地了一套混合分支策略：main只接受MR、release分支冻结、feature分支强制squash，配合GitLab 16.9的push rules和Jenkins 2.452多分支流水线，把平均合并时间从26小时压缩到4.5小时，线上事故回滚降到8分钟内。本文把完整的分支模
一个日请求量约80万的商品详情接口，P99从2.3s降到180ms，服务器从8台减到3台。本文用py-spy火焰图定位到ORM的N+1查询，配合索引重写、Redis两级缓存和连接池调参，附完整代码与wrk压测对比数据。FastAPI 0.110和Flask 3.0两个版本都跑了一遍，结论略有差异。
三个月前，我们团队还在为“直接push主干”付出代价：平均每周3次构建失败，代码评审形同虚设，紧急修复经常引入新Bug。本文记录了我们基于Git 2.30.2 + GitLab 14.3 + Jenkins 2.303.1构建的完整Git工作流体系。通过实施严格的分支策略、强制Code Review（至少1人批准，关键模块2人）、以及自动化CI/CD流水线（构建+单元测试+部署，全流程平均18分钟
