pprof 数据到底怎么用：Go 为什么要沿三条线把 goroutine 泄漏钉回代码
pprof 抓回来了，最容易发生的事不是你看不懂。
而是你看懂了一半：知道一批 goroutine 卡在 main.worker，知道等待状态是 [chan receive]，知道创建点也在栈里，可下一步还是开始全局搜 context、搜 …
27
5月
10
篇文章
相关文章
共 10 篇
27
5月
goroutine 为什么不能靠猜：Go 排查第一步要先用 NumGoroutine 和 pprof 采样
线上 goroutine 数开始往上爬，很多人的第一反应是猜。
是不是 context 泄漏？是不是超时没生效？是不是某个 channel 没人读？是不是锁没释放？
这些猜法都可能对。
但问题在于，你现在还没有证据。你只有一个数字 …
27
5月
Go 为什么不把 Cancel 放进 Context 接口：观察权和控制权必须分开
上篇讲了 Go 为什么宁可让你多传一个 ctx 参数。
这篇往下走一步：既然 context 已经显式传进来了，为什么它自己没有 Cancel()？
这件事看起来很别扭。Context 明明能被取消，Done() 明明会关闭，Err() 明 …
27
5月
Go 为什么宁可让你多传一个 ctx 参数
你写一个接口，ctx 从 handler 传到 service，再传到 repo。
中间两层明明不关心超时，也不读取 trace id，却还是要把 ctx 原样递下去。
代码看起来像这样：
|
26
5月
context.WithValue 不是 map，是一条链
函数签名很干净，代码却越来越难查。
你打开一个 Go 函数，只看到一个 ctx context.Context。再往里翻，发现 user id 从 ctx.Value 里取，tenant 从 ctx.Value 里取，trace id 从 …
26
5月
WithTimeout 的 cancel，不是你想象的那个“超时按钮”
接口已经超时了，goroutine 曲线还在往上爬。
上篇讲到这里时，我们先压住了一个误判：这通常不是 context 没生效，而是你的 goroutine 没有响应取消信号。
但还有一个更隐蔽的问题，很多 Go 代码每天都在写：
|
25
5月
超时到了，goroutine 还在涨：context 到底背不背这个锅？
接口超时了，goroutine 曲线还在往上爬。
日志里已经打出 context deadline exceeded，调用方也早就不等了。你盯着监控看了十分钟，心里开始冒出那个判断：是不是 context.WithTimeout 没生效？ …
21
5月
Go 服务 goroutine 涨了，别先猜：按这条流程查 context 泄漏
线上 goroutine 数开始往上爬，最怕的不是它涨。
最怕的是你盯着监控看了十分钟，然后开始猜：是不是 context 泄漏了？是不是超时没生效？是不是某个 channel 卡住了？
这些猜法都有可能对，也都有可能错。 …
20
5月
Go 为什么宁可让你多传一个 ctx 参数
很多 Go 开发者第一次系统用 context，都会嫌它啰嗦。
一个请求从 handler 进来，service 要传 ctx，repo 要传 ctx，RPC client 要传 ctx，连中间那些根本不关心超时和取消的函数，也要机械地把 …
20
5月
Go context 最容易被误用的地方：以为 cancel 会替你收拾现场
线上接口开始超时，goroutine 数一路往上涨。
你第一反应可能是：不是已经传了 context.WithTimeout 吗？超时到了，goroutine 不就该停了吗？
这就是 Go context 最容易被误用的地方。 …