会话桶科技
后端开发与线上疑难排查
一人技术工作室，专注 Go 服务端开发、性能调优与线上疑难问题排查。
十年后端经验，对交付结果负责。
Services
能帮你做什么
后端系统开发
Go 服务端从零搭建到上线，含数据库设计、接口规范与部署方案。
性能诊断与优化
接口慢、内存涨、CPU 打满、数据库扛不住——定位根因并给出改造方案。
架构咨询与代码审查
分库分表、缓存策略、并发模型的选型评审，以及现有代码的问题排查。
端到端交付
需要前端页面、部署脚本、监控告警配合的部分一并做掉，你不用再去协调第二个人。
Writing
技术实践
写代码这件事，门槛已经被 AI 拉低了。难的是另一类问题：文档写得明明白白、AI 答得斩钉截铁，照做却是错的。
下面几篇都属于这类——官方注释教你开的开关让 QPS 掉了两成，加一条 CPU 限制让尾延迟涨了三倍，pprof 里找不到泄漏可内存一直涨到 OOM。这种时候缺的不是更多代码，是判断该往哪儿查。
所以这里没有客户 logo。真实的排障复盘更能说明问题：现象、误判、定位过程、根因、以及最后取舍了什么。
8 个 goroutine 各写各的计数器，没有锁，比单线程慢 13 倍
八个 goroutine，每个只写自己那一格，互不重叠，没有锁，没有 channel，`-race` 跑出来干干净净。它比一个 goroutine 从头干到尾**慢十三倍**。
我的网关一个字段都没改，订单号却变了
没有报错、没有 panic、没有超时，`Unmarshal` 返回 nil，`Marshal` 也返回 nil，日志从头到尾干干净净。数据就这么安安静静地错了——一个只做转发的网关，代码里一行都没碰过 `order_id`，订单号却在它手里变成了另一个数。
服务内存涨到 OOM，可我真的没有内存泄漏
内存曲线一路只涨不跌，最后被 OOM Killer 干掉。可我翻遍 pprof 的 heap profile，找不到任何一处「忘了释放」——每个对象看起来都该在。没有泄漏，它就是在漏。
我把 Redis 的 IO 多线程打开，QPS 不升反降了 20%
一个写在 redis.conf 里、官方注释明明白白教你开的性能开关，我照着开了，QPS 没涨，反而掉了两成。这一篇是我自己交的学费。
我们给 Go 服务限了 CPU，P99 反而涨了 3 倍
给容器加一条再正常不过的 CPU 限制，尾延迟不降反升，涨了 3 倍。这一篇讲清楚它为什么会这样，以及我当时是怎么一步步想错的。
How it works
合作方式
- 按项目或按周结算，需求明确后给固定报价
- 支持远程协作，可配合你现有的开发流程
- 交付含源码、部署文档与必要的交接说明