Go

为什么你只改了 base_url，LLM API 还是报 404？

你在 Go 项目里接一个新的模型供应商。

文档写着“OpenAI compatible”。你心里一松：那不就是改三个值吗？

1
2
3

BaseURL: …

Go 为什么不怕 goroutine 死循环：抢占不是玄学，是一套停机协议

把 GOMAXPROCS 设成 1，再启动一个没有函数调用、没有 I/O、没有 sleep 的死循环。

按很多人对 goroutine 的理解，程序应该完了：唯一的 P 被这个 goroutine 一直占着，其他 goroutine 没机会 …

Go 调度器真正厉害的地方：线程卡住了，P 不能跟着陪葬

把 GOMAXPROCS 设成 1，再让一个 goroutine 卡在 syscall.Read 里。

按直觉，整个 Go 程序应该只剩一个执行名额。这个名额被卡住了，其他 goroutine 也该一起停。

但你真跑一下，会看到另一件事 …

goroutine 泄漏不一定忘了 cancel：还要看 sender 和 receiver 谁没回家

goroutine 泄漏最讨厌的地方，不是它会炸，而是它不炸。

它先是悄悄多几个，再多几十个，最后把内存、延迟、CPU 一起拖下水。你回头看日志，发现代码没报错；你再看监控，发现曲线只是在往上爬。

很多人看到这种情况，第一反应是：是不是忘了 …

goroutine 涨了为什么别先加 buffer：chan send 和 chan receive 不是一类问题

goroutine 从 200 慢慢涨到 2 万，线上服务还没挂，但你知道它不对劲。

监控图上那条线不陡，甚至有点温和。它不像事故，更像一个迟早会来的事故。

这时候很多人的第一反应是：把 channel buffer 调大一点。 …

同步原语到底同步了什么：Go 为什么要用 happens-before 解释 channel 和 Mutex

代码评审里经常出现这种争论：一个 goroutine 写完结果，close(done)；另一个 goroutine 等 <-done 再读结果。有人看着觉得多此一举：这不就是通知一下吗？换成一个 bool，或者 sleep 一小会儿， …

Go 为什么不承认 ready=true 就是发布：happens-before 才是并发安全的证据

线上最烦的并发 bug，往往不是崩得轰轰烈烈，而是偶尔读到一个不该出现的旧值。

配置已经加载了，日志也打了“ready”，另一个 goroutine 却像没看见一样，读到的还是旧数据。你盯着代码看半天，越看越觉得冤：明明是先写数据，再把 …

Go 内存为什么不能都怪 GC：goroutine 泄漏、无界缓存和高分配速率修法完全不同

服务又 OOM 了。

Pod 刚重启，群里已经开始出方案：GOMEMLIMIT 设低一点，GOGC 调一下，limit 先加 1Gi，GC 日志再翻一遍。

这些动作有时候能救火，但经常救不到根上。

因为很多 Go 服务所谓的“内存泄漏”，根 …

OOMKilled 到底是谁动的手：Go 为什么要先看 kubectl describe 再做 pprof diff

服务又被 OOMKilled 了。

Pod 刚重启，群里已经开始报菜名：把 GOGC 调低一点，给 GOMEMLIMIT 设个值，容器 limit 再加 1Gi，顺手翻一下 GC 日志。

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

你现在看到的是“尸体 …

GC 调优到底先看什么：Go 为什么要从 live heap 开始，而不是先改 GOGC

上篇讲完 GOGC、GOMEMLIMIT 和 STW，很多人真正卡住的地方才刚开始。

不是“不知道这些参数是什么”，而是线上真的出问题时，不知道下一步该干什么。

服务 p99 每隔几十秒抖一下，GC CPU 看起来有 5%。有人说把 …

Go 为什么调高 GOGC 会换来 OOM：GOMEMLIMIT 不是替你付账的人

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

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

这个动作看起来很合理。

CPU 下来了 …

pprof 数据到底怎么用：Go 为什么要沿三条线把 goroutine 泄漏钉回代码

pprof 抓回来了，最容易发生的事不是你看不懂。

而是你看懂了一半：知道一批 goroutine 卡在 main.worker，知道等待状态是 [chan receive]，知道创建点也在栈里，可下一步还是开始全局搜 context、搜 …

goroutine 为什么不能靠猜：Go 排查第一步要先用 NumGoroutine 和 pprof 采样

线上 goroutine 数开始往上爬，很多人的第一反应是猜。

是不是 context 泄漏？是不是超时没生效？是不是某个 channel 没人读？是不是锁没释放？

这些猜法都可能对。

但问题在于，你现在还没有证据。你只有一个数字 …

Go 为什么不把 Cancel 放进 Context 接口：观察权和控制权必须分开

上篇讲了 Go 为什么宁可让你多传一个 ctx 参数。

这篇往下走一步：既然 context 已经显式传进来了，为什么它自己没有 Cancel()？

这件事看起来很别扭。Context 明明能被取消，Done() 明明会关闭，Err() 明 …

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

你写一个接口，ctx 从 handler 传到 service，再传到 repo。

中间两层明明不关心超时，也不读取 trace id，却还是要把 ctx 原样递下去。

代码看起来像这样：

 1
 2
 3
 4
 5
 6
 7
 8 …

Go GC 为什么不能只看 STW：三色标记和写屏障才是你该先算的账

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

曲线不陡，不像雪崩。它只是每天往上爬一点，重启以后掉下来，过几天又回到老地方。告警一响，群里很快会出现两个动作：先怀疑泄漏，再问 GOGC 要不要调。

这两个反应都不离谱，但都太早。

在 Go …

Go 为什么不让 selectgo 做 O(1) 抽奖：case 越多，runtime 付出的账越多

很多人写 select，脑子里都有一个抽奖箱。

几个 case 往里一扔，runtime 随机摸一个。哪个 channel 先 ready，哪个就中；都没 ready，就看 default；没有 default，就等。

这个理解不能说全错， …

Go 为什么让 close(ch) 批量唤醒等待者，而不是只给 channel 关个门

线上最烦的 channel 问题，往往不是“发不出去”。

而是你以为自己在等一个值，结果等来的是零值；你以为 close(ch) 只是关门，结果它把一批阻塞的 goroutine 全部叫醒；你以为 nil channel 和 closed …

Go 为什么宁可让 chansend 卡住，也不让你误以为 ch <- v 发成功了

goroutine dump 里刷出一排 [chan send]，你知道它卡住了。

但更麻烦的问题是：它到底卡在哪？

是 channel 本身是 nil？是已经有人在等接收，只差一次交付？是 buffer 满了？还是它已经被 runtime …

context.WithValue 不是 map，是一条链

函数签名很干净，代码却越来越难查。

你打开一个 Go 函数，只看到一个 ctx context.Context。再往里翻，发现 user id 从 ctx.Value 里取，tenant 从 ctx.Value 里取，trace id 从 …

WithTimeout 的 cancel，不是你想象的那个“超时按钮”

接口已经超时了，goroutine 曲线还在往上爬。

上篇讲到这里时，我们先压住了一个误判：这通常不是 context 没生效，而是你的 goroutine 没有响应取消信号。

但还有一个更隐蔽的问题，很多 Go 代码每天都在写：

1 …

超时到了，goroutine 还在涨：context 到底背不背这个锅？

接口超时了，goroutine 曲线还在往上爬。

日志里已经打出 context deadline exceeded，调用方也早就不等了。你盯着监控看了十分钟，心里开始冒出那个判断：是不是 context.WithTimeout 没生效？ …

channel 最容易翻车的不是发送接收，而是 close

上一篇讲到最后，其实只把问题说完了一半。

如果你面对的是任务、结果、信号和访问权交接，channel 确实比 mutex 更顺手。它能把 goroutine 之间的关系写出来，让代码不只是在“保护状态”，而是在表达一段通信。

但很多 …

channel 还是 mutex？先回答这五个问题

上一篇说到一个很典型的场景：为了写得“更 Go”，有人把一个普通 cache 写成了小型 RPC。

锁确实没了。

但你多了 request、reply channel、owner goroutine、退出顺序、取消处理。读一个 map，本来 …

为了写得“更 Go”，他把一个 cache 写成了小型 RPC

有些 Go 代码，一看就知道作者很努力。

为了让一个普通 cache 看起来“更 Go”，他把 sync.RWMutex 拿掉了，换成一个专门的 goroutine 来“拥有”这份状态。每次 Get，调用方先构造 request，发进 …

Go 1.25 的 map 已经换了一套发动机：Swiss Table 到底改了什么

你读过的很多 Go map 文章，可能已经过时了。

它们还在讲 hmap、bmap、overflow bucket、load factor 6.5，还会画一张 bucket 后面挂着 overflow bucket 的图。那些内容不是没有价 …

Go GMP 里最容易背错的不是 G 和 M，而是 P

很多人聊 Go 调度器，开口就能背：G 是 goroutine，M 是 machine，P 是 processor。

背完以后，问题来了：为什么已经有 M 这个 OS 线程，还要多一个 P？

如果这个问题答不上来，GMP 其实还没真的理解。 …

Go 数组为什么这么硬？因为它要把边界写进类型里

同样是复制，一个 [32]byte 的 hash 往往很安全，一个 struct 里的 [4096]int 却可能把性能拖得很难看。

这不是 Go 数组“好不好用”的问题，而是你有没有把它当成正确的东西。

很多 Go 开发者平时几乎不直接写 …

Go 里真正难懂的不是 slice，是它背后的数组

一次 append，把原来的数据改坏了。

代码看起来很普通：从一个 slice 里切一段出来，往这段里追加一个元素。你以为只是改了新变量，结果回头一看，原 slice 里的某个位置也变了。

这类问题很烦，因为它不像空指针那样直接炸给你看。它 …

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 服务 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 基座的真实原因：不 …