Go

ready=true 不是发布：Go 内存模型真正要你保证什么

线上偶现一个很烦的 bug：配置已经加载了，日志也打印了“ready”，但另一个 goroutine 读到的还是旧值。

代码看起来没什么毛病：先写数据，再把 ready 置成 true。读的一侧先等 ready，再读数据。人脑看这段逻辑，很 …

Go 服务被 OOMKilled，别先怪 GC

服务又被 OOMKilled 了。

Pod 刚重启，群里已经有人开始翻 GC 日志。有人说 GC CPU 到了 20%，有人说把 GOGC 调低一点，还有人建议直接上 GOMEMLIMIT。

这些动作不一定错，但顺序错了。 …

Go GC 占 CPU 5%，到底要不要调 GOGC？

服务 p99 每隔几十秒抖一下。

监控里 GC CPU 大概 5%，不算夸张，但曲线很准：GC 一来，延迟就往上冒。群里很快有人提议：把 GOGC 从 100 调到 200，先让 GC 少跑几次。

这个动作看起来很合理。

CPU 下来了 …

内存一直涨，不一定是泄漏：Go GC 真正在做什么

服务内存从 800MB 慢慢涨到 2.6GB。

曲线不陡，不像雪崩。它只是每天往上爬一点，重启以后掉下来，过几天又回到老地方。告警响了，群里第一句话通常是：是不是内存泄漏？

这个判断不算错，但太急。

在 Go 服务里，内存持续上涨可能是真泄 …

加 buffer 不是修 bug：Go channel 阻塞排查实战

goroutine 数量从 200 慢慢涨到 2 万。

监控图上那条线，不陡，但一直在爬。就像水龙头没拧紧——不喷，但也不会停。

你的第一反应是什么？

加大 buffer。

make(chan int, 100) 改成 make(chan …

Go channel 不是高级锁，它是一种组织并发的语言

有人为了写得“更 Go”，把一个简单 cache 包成了 channel 协议。

每次 Get，先构造 request，发给 owner goroutine，再等 response channel 返回。还要处理 …

Go channel 源码不是在讲队列，而是在讲 goroutine 怎么排队

goroutine dump 里满屏 chan send，你知道它卡住了。

但它到底卡在哪里？

是缓冲区满了？没有 receiver？被 select 挂进了等待队列？还是 channel 被 close 之后才醒过来，然后 panic？ …

Go 服务 goroutine 涨了，别先猜：按这条流程查 context 泄漏

线上 goroutine 数开始往上爬，最怕的不是它涨。

最怕的是你盯着监控看了十分钟，然后开始猜：是不是 context 泄漏了？是不是超时没生效？是不是某个 channel 卡住了？

这些猜法都有可能对，也都有可能错。 …

Go 为什么宁可让你多传一个 ctx 参数

很多 Go 开发者第一次系统用 context，都会嫌它啰嗦。

一个请求从 handler 进来，service 要传 ctx，repo 要传 ctx，RPC client 要传 ctx，连中间那些根本不关心超时和取消的函数，也要机械地把 …

Go context 最容易被误用的地方：以为 cancel 会替你收拾现场

线上接口开始超时，goroutine 数一路往上涨。

你第一反应可能是：不是已经传了 context.WithTimeout 吗？超时到了，goroutine 不就该停了吗？

这就是 Go context 最容易被误用的地方。 …

TypeScript 押注 Go：10 倍提速背后，不是语言胜负，是工程约束

TypeScript 的 10 倍提速，最容易被讲歪。

一歪成“Go 打赢 Rust”。

再歪成“以后 TypeScript 业务代码快 10 倍”。

这两个说法都抓人，也都危险。前者把工程决策讲成语言饭圈，后者直接把性能场景讲错了。

真正 …

别再让后端手写脚本了：我搭了一套可复用的企业 CLI 基座，命令扩展靠 YAML

内部工具越堆越多，每个新服务都要重新写一遍登录、鉴权、日志、错误处理。

新来的同事拿到一堆脚本，不知道哪个能跑、哪个已经废了。测试环境和生产环境的 token 混着用，一不小心就把测试数据写到生产。

这是我搭这套 CLI 基座的真实原因：不 …