Go on Zampo Blog

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

Fri, 22 May 2026 16:40:00 +0800

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

代码看起来没什么毛病：先写数据，再把 ready 置成 true。读的一侧先等 ready，再读数据。人脑看这段逻辑，很容易得出一个结论：既然 ready 已经是 true，前面的数据当然也该准备好了。

问题就在这里。

在 Go 里，ready=true 不等于发布。普通变量上的“先写后读”，也不等于 goroutine 之间有可见性保证。

并发安全不是让代码看起来有先后，而是让规范承认它有先后。

这篇是 Go 内存模型系列的第一篇。它不打算把你拖进 CPU 指令、缓存一致性协议和汇编细节里。我们先解决一个更常见、更工程化的问题：goroutine A 写了变量，goroutine B 什么时候保证能看到？

答案只有一个：两边要存在 happens-before 关系。

最危险的代码，通常看起来最顺

先看这段很多人都写过的代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


var data string
var ready bool

go func() {
 data = "payload"
 ready = true
}()

for !ready {
}
fmt.Println(data)

直觉上，写入顺序很清楚：data 先被赋值，ready 后变成 true。读的一侧又是看到 ready 才打印 data，似乎不会出错。

Go 服务被 OOMKilled，别先怪 GC

Fri, 22 May 2026 00:01:00 +0800

服务又被 OOMKilled 了。

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

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

OOMKilled 是结果，不是根因。它只说明容器被内核杀掉了，不说明是谁把内存吃掉了。可能是 Go heap 真的在涨，可能是 goroutine 泄漏把栈和引用一起拖大，可能是 alloc_space 很高导致 GC 忙，可能是 RSS 里有 cgo、mmap、tmpfs，也可能只是容器 limit 给得太紧。

Go 服务的内存问题，最怕一句话定性。

一旦你把所有问题都叫“GC 问题”，排查就会变成调参赌博：今天调 GOGC，明天加 limit，后天又开始怀疑 pprof 没抓准。真正稳定的做法，是先把几条线拆开：Go 堆、Go runtime 管理的内存、RSS、容器 limit，以及业务生命周期。

第一步不是调参数，是确认谁杀了你

线上看到内存上涨，第一件事不是打开 pprof，也不是改 GOGC。

先确认事故事实。

1
2
3
4
5


kubectl describe pod <pod> -n <ns>
kubectl logs <pod> -n <ns> --previous
kubectl top pod <pod> -n <ns> --containers
kubectl get pod <pod> -n <ns> \
 -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}'

你要先回答几个问题：

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

Thu, 21 May 2026 23:30:00 +0800

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

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

这个动作看起来很合理。

CPU 下来了，GC 日志没那么密了，p99 也安静了几天。然后另一个问题来了：容器内存开始逼近 limit，某个高峰期被 OOMKilled。大家又把 GOGC 调回去，延迟抖动也跟着回来。

这就是很多 Go GC 调优的真实状态：不是不会调参数，而是没想清楚自己到底在买什么。

GOGC 调的是账期，不是魔法。

调高它，相当于允许堆多长一段时间，用内存换 CPU；调低它，相当于让 GC 更勤快，用 CPU 换内存。至于 GOMEMLIMIT，它不是另一个版本的 GOGC，而是在告诉 runtime：这个进程由 Go 管的内存，最好别越过这条线。

所以这篇不打算把 GC 参数逐个解释一遍。线上真正需要的是一条决策路径：要不要调，调什么，调多少，什么时候停手。

先别问 GOGC 设多少，先问谁在付账

Go 官方 GC Guide 给过一个很关键的公式：

1

Target heap memory = Live heap + (Live heap + GC roots) × GOGC / 100

这句话不用背，抓住意思就行。

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

Thu, 21 May 2026 20:25:00 +0800

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

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

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

在 Go 服务里，内存持续上涨可能是真泄漏，也可能是 live heap 变大了，可能是 GOGC 目标让下一轮回收来得更晚，也可能是短命对象太多，把 GC 拖进了频繁工作。还有一种更容易误判：heap 已经回收了，但 RSS 没有马上按你想象的方式降下来。

内存涨，不等于内存泄漏。

要把这件事查清楚，不能只盯 RSS。你得知道 Go GC 什么时候启动、怎么判断对象还活着、为什么需要写屏障、哪里会停顿，以及哪些参数是真的能调。

GC 不是保洁员，是成本调度器

很多人对 GC 的直觉是“内存不用了，运行时帮我扫掉”。这个说法只对了一半。

真正重要的是另一半：GC 每扫一次，都要花 CPU；扫得太勤，CPU 被回收器吃掉，服务吞吐和延迟会受影响。扫得太晚，内存峰值又会涨上去，容器可能先把你杀掉。

所以 Go GC 不是等地上脏了才来的保洁员。它更像一个拿着预算表的人：上一轮还有多少对象活着？再往后拖一点，内存能不能接受？现在开始扫，CPU 能不能接受？

Go 官方 GC Guide 讲得很清楚：GC 主要消耗 CPU 和物理内存。想省 CPU，就得允许堆多长一会儿；想省内存，就得让 GC 更频繁地工作。

这就是 GOGC 的本质。

GOGC=100 不是“内存达到 100MB 触发 GC”。它的意思更接近：在上一轮存活堆的基础上，允许新分配对象按约 100% 的比例增长，再触发下一轮 GC。Go 1.19 之后，目标堆计算还会把 GC roots 的成本纳入进来，可以简化理解为：

1

下一轮目标 ≈ live heap + (live heap + GC roots) × GOGC / 100

GOGC 调的是成本，不是情绪。

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

Thu, 21 May 2026 18:30:00 +0800

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

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

你的第一反应是什么？

加大 buffer。

make(chan int, 100) 改成 make(chan int, 1000)。重启。观察。好像好了。

三天后，又涨回来了。

这不是运气差。这是 Go 服务最常见的线上问题之一：channel 阻塞导致 goroutine 泄漏。而"加 buffer"是社区里最流行、也最没用的解法。

buffer 只是把崩溃推迟了。问题的根因——谁在等谁、谁该退出、谁该 close——一个都没解决。

这篇文章做一件事：从"goroutine 涨了"这个信号出发，走一遍完整的排查路径，把 channel 的六个最常见陷阱逐个拆开。

不是背 API。

是下次线上出问题的时候，你知道先看什么。

发现：怎么知道 channel 卡住了

排查 channel 阻塞的第一步不是看代码，是看数字。

runtime.NumGoroutine()：最简单的基线

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import "runtime"

func init() {
 go func() {
 ticker := time.NewTicker(30 * time.Second)
 defer ticker.Stop()
 for range ticker.C {
 log.Printf("goroutines: %d", runtime.NumGoroutine())
 }
 }()
}

这段代码放到任何 Go 服务的 init() 里，每 30 秒打一行日志。goroutine 数量只升不降，大概率有泄漏。

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

Thu, 21 May 2026 16:02:00 +0800

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

每次 Get，先构造 request，发给 owner goroutine，再等 response channel 返回。还要处理 context、close、退出顺序、goroutine 泄漏。

最后代码确实没有显式 sync.RWMutex 了。

但问题也来了：本来一把锁能讲清楚的事，被写成了一套小型 RPC。

这不是优雅。

这是绕远。

Go 社区有一句被反复引用的话：

Do not communicate by sharing memory; instead, share memory by communicating.

很多人把它理解成：Go 不喜欢锁，channel 更高级，能用 channel 就别用 mutex。

这个理解太粗了。

channel 的价值不是把锁藏起来，而是把通信显式写出来。mutex 也不是“不 Go”，它就是保护共享状态的直接工具。

真正要问的不是：channel 和 mutex 谁更高级？

真正要问的是：你现在到底是在传东西，还是在护东西？

channel 首先讲的是结构，不是性能

Rob Pike 在那场很有名的演讲《Concurrency is not Parallelism》里，一直在压一个区分：concurrency 是 structure，parallelism 是 execution。

并发不是“同时跑得更快”的同义词。

并发先是一种组织程序的方式：把一件事拆成多个可以独立执行的单元，再让它们通过通信协调。

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

Thu, 21 May 2026 15:17:00 +0800

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

但它到底卡在哪里？

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

如果只停留在“channel 是 goroutine 之间通信的管道”，这些问题永远说不清。

ch <- v 这一行代码，在 Go runtime 里不是一句“把数据塞进队列”。它会走过 hchan、环形缓冲区、sendq / recvq、sudog、gopark、goready，最后决定一个 goroutine 是继续跑，还是挂起来等别人。

Go 的 channel 设计长期受 CSP 思想影响。Rob Pike 在 Go 早期设计和并发模型传播里反复强调：不要通过共享内存来通信，而要通过通信来共享内存。

这句话听起来像哲学，但到了 runtime 里，它会变成很具体的结构：谁在等谁，数据放在哪里，哪个 goroutine 应该被唤醒。

这篇只做一件事：沿着 Go 1.25.4 的 runtime/chan.go 和 runtime/select.go，把 channel 的几条关键路径走一遍。

不是为了背源码。

是为了让你下次看到 chan send、chan receive、close、select 的时候，脑子里有一张清楚的运行时地图。

channel 不是无锁队列，它是带调度语义的协作原语。

hchan：channel 在运行时到底长什么样

Go 代码里你写的是：

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

Thu, 21 May 2026 13:45:00 +0800

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

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

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

runtime.NumGoroutine() 只能告诉你“现在有多少 goroutine”。它不会告诉你这些 goroutine 停在哪里，也不会告诉你是谁创建的，更不会告诉你为什么没有退出。

排查这类问题，第一步不是解释 context 原理。

第一步是采样。

这篇是 Go context 系列第三篇。前两篇讲过 context 的生命周期、cancel 的边界，以及 Go 为什么坚持显式传 ctx。

这一篇换一个角度：不从源码开始，从排查现场开始。

一套最小流程就够了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


goroutine 涨了
 ↓
先采样，确认趋势
 ↓
用 pprof 找等待点
 ↓
用 go vet 查静态路径
 ↓
按创建路径、取消路径、响应路径回到代码
 ↓
修复，再验证

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

Wed, 20 May 2026 22:20:00 +0800

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

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

看多了以后，很自然会冒出一个问题：为什么不能像 Java、Node.js、Python 那样，把上下文放进运行时里？

Java 有 ThreadLocal。Node.js 有 AsyncLocalStorage。Python 有 contextvars。它们都能让深层函数不改签名，也拿到当前请求的 trace id、用户信息、日志上下文。

Go 偏不。

它宁可让你在函数签名里多写一个参数：

1
2
3


func DoSomething(ctx context.Context, arg Arg) error {
 // ...
}

这不是因为 Go 不知道隐式上下文更省事。恰好相反，这正是 Go 的取舍：它愿意把“不优雅”摆在台面上，换调用链里的生命周期可见。

显式传参，最先付出的就是签名噪音

先承认代价。

ctx context.Context 作为首参，会污染函数签名。尤其在分层很深的服务里，中间层经常只是 pass-through：自己不用 ctx，但必须接住它，再传给下一层。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


func (h *Handler) Create(ctx context.Context, req CreateReq) error {
 return h.service.Create(ctx, req)
}

func (s *Service) Create(ctx context.Context, req CreateReq) error {
 return s.repo.Insert(ctx, req.UserID, req.Payload)
}

func (r *Repo) Insert(ctx context.Context, userID string, payload []byte) error {
 _, err := r.db.ExecContext(ctx, `insert into ...`, userID, payload)
 return err
}

这段代码里，Handler 和 Service 可能都没有真正“使用” ctx。它们只是把一段调用生命周期交给更底层的数据库调用。

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

Wed, 20 May 2026 17:50:00 +0800

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

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

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

context 不负责替你停掉 goroutine。它只负责把“该停了”这句话传到门口。门里的人听不听、什么时候退场，要看你自己的代码。

这篇是 Go context 系列的第一篇。先不急着讲 HTTP、gRPC、database/sql 这些框架怎么接入，也不急着把所有 API 列一遍。

我们先把最底下这层讲清楚：context 到底是什么，cancel 到底做了什么，为什么 WithTimeout 后面那句 defer cancel() 不是仪式感，而是资源释放动作。

事故通常不是从源码开始的

真实排查里，很少有人一上来就打开 context.go。

更常见的是这样的场景：

一个接口偶发超时。压测一上来，P99 开始抖，错误日志里出现 context deadline exceeded。你看监控，CPU 没打满，内存也没爆，但 goroutine 数不太对，一路往上爬。

然后你打开 pprof：

1

curl -s 'http://127.0.0.1:6060/debug/pprof/goroutine?debug=1'

采样里有一批 goroutine 卡在业务 worker 上，等某个 channel，或者等 <-ctx.Done()。

这时候最危险的判断是：

“是不是 Go 的 context 泄漏了？”

大多数时候，不是。

更可能是你的调用链里少了三件事之一：创建了 timeout context 但没及时 cancel；启动了 goroutine 但没监听 ctx.Done()；或者监听了 Done，却没有确保取消路径真的跑到。

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

Tue, 19 May 2026 20:30:00 +0800

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

一歪成“Go 打赢 Rust”。

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

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

真正有意思的地方不是 Go 有多神，也不是 Rust 或 C# 有多不行，而是 TypeScript 团队这次面对的目标非常特殊：他们不是要从零设计一个新编译器，而是要把一个成熟、庞大、被整个前端生态依赖的工具链，迁到 native 实现里。

这件事一旦说清楚，Go 为什么胜出，就没那么玄学了。

10 倍提速，先别理解错

官方博客里的 10 倍，不是说你写出来的 JavaScript 业务代码运行快 10 倍。

TypeScript 最后还是编译成 JavaScript，线上跑得快不快，主要看 JS 引擎、业务逻辑、网络、渲染、数据结构和运行时环境。TypeScript 这次提速，发生在开发期工具链：tsc、类型检查、项目加载、语言服务、编辑器响应。

这区别很重要。

因为一个错的期待，会毁掉一个本来很有价值的技术升级。

官方 benchmark 里，VS Code 代码库的 tsc 检查从 77.8 秒降到 7.5 秒，Playwright 从 11.1 秒降到 1.1 秒，TypeORM 从 17.5 秒降到 1.3 秒。编辑器加载 VS Code 项目，也从约 9.6 秒降到约 1.2 秒。

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

Sat, 18 Apr 2026 12:00:00 +0800

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

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

这是我搭这套 CLI 基座的真实原因：不是为了让工程师更极客，而是为了把内部能力收敛成一个人和 Agent 都能调用的统一入口。

这个项目我已经用在企业内部，核心代码公开。看完你能照着自己搭一套。

一、我为什么把企业后台能力做成 CLI

先说判断。

GUI、API、CLI 这三层，很多企业只做了前两层：后台页面给人点，API 给系统调。但中间那层——对人足够友好、对脚本足够稳定、对 Agent 足够结构化——一直是空的。

后果就是：

业务同学要操作后台，点到手软
工程师要写脚本，每个脚本都重新处理一遍认证、日志、错误
Agent 要调用业务，得直接拼 API，参数错了都不知道怎么报错

CLI 正好卡在中间。

但企业 CLI 不是把几个 API 包成命令就完了。我搭这套基座时，核心就一个原则：稳定层先代码化，业务层再规格化。

什么意思？

认证、环境、HTTP 请求、Header 注入、打包发布——这些是稳定层，一次搭好，长期复用。

业务命令——这些是变化层，用 YAML 规格化，扩展时不改核心代码。

这样搭出来的 CLI，命令越多，扩展越快。而不是命令越多，代码越乱。

二、这套 CLI 基座的骨架

项目结构长这样：

.
├── cmd/ # Cobra 命令入口
│ ├── root.go # 根命令，加载 YAML 动态命令
│ ├── auth_login.go # 登录回调
│ ├── token_refresh.go # Token 刷新
│ └── oauth_injected.go # OAuth 凭据注入（构建时生成）
├── internal/
│ ├── auth/ # 认证层：登录、token、device_id
│ ├── httpx/ # 请求层：HTTP client、Header 注入、401 refresh
│ ├── runtime/ # 执行层：YAML 解析、Cobra 命令注册、请求执行
│ └── store/ # 存储层：profile、token 本地持久化
├── specs/
│ ├── groups/ # 业务命令规格
│ │ └── order/
│ │ ├── group.yaml # 订单组配置
│ │ └── commands/
│ │ └── list.yaml # 订单查询命令
│ └── embed.go # go:embed 把 YAML 编译进二进制
└── scripts/
 └── build-with-oauth.sh # 多环境、多平台打包脚本

核心分层：