Go在微服务中不掉链子：goroutine轻量（2KB栈）、静态编译单文件镜像小（<15MB）、错误显式处理、标准库开箱即用，兼顾高性能与工程稳定性。
大厂用 Go 做微服务，不是跟风，而是因为几个关键环节它确实“不掉链子”：并发模型能扛住流量洪峰、编译产物能直接扔进容器跑、错误边界清晰到敢上生产、标准库够用到不用急着找第三方包。
goroutine 真的比线程轻？别光听宣传，看实际开销
Go 的 goroutine 初始栈只有 2KB，调度由 Go 运行时（GMP 模型）完成，不陷入内核态。这意味着：
- 启动 10 万个
goroutine，内存占用通常不到 200MB；同等数量的 OS 线程，在 Linux 上可能直接 OOM -
go http.ListenAndServe()启动的服务，默认为每个请求分配一个goroutine，无需手动池化或复用 - 但注意：
goroutine不是免费的——如果大量协程阻塞在未关闭的channel或死循环里，会累积泄漏，必须配pprof定期查runtime.NumGoroutine()
为什么微服务部署偏爱 Go 编译出的二进制？
Go 默认静态链接，go build -o service ./cmd/main 输出的是单个可执行文件，不含外部依赖。这带来三个硬性好处：
- Docker 镜像可以基于
scratch或alpine构建，最终镜像常小于 15MB；Java/Python 服务镜像普遍 200MB+，拉取和启动慢 - 没有
JVM或node_modules版本冲突问题，go version和go.mod锁定后行为确定 - CI/CD 流水线里只需验证二进制哈希值，跳过运行时环境校验——这对跨集群灰度发布很关键
HTTP 服务写起来简单，但 production-ready 要绕过哪些坑？
用 net/http 写个 demo 很快，但真实微服务不能只靠 http.HandleFunc。常见疏漏包括：
立即学习“go语言免费学习笔记（深入）”；
- 没设
http.Server.ReadTimeout/WriteTimeout，导致慢客户端拖垮整个连接池 - 日志直接用
fmt.Println，无法结构化、无 trace_id 关联，线上排查等于盲人摸象 - 没用
context.Context传递超时和取消信号，下游调用（如 gRPC、DB）无法及时中断 - 错误处理写成
if err != nil { log.Fatal(err) }——这会让整个服务崩掉，而不是仅失败单个请求
标准库够用，但生态选型容易踩什么雷？
Go 生态强在“轮子少而稳”，但选型仍需警惕：
-
gin和echo性能接近，但gin中间件机制更成熟；fiber基于fasthttp，性能高但不兼容net/http接口，中间件迁移成本高 -
grpc-go是事实标准，但 proto 文件生成代码后，若没加//go:generate protoc...到 Makefile，CI 构建会失败 - 用
go-zero或kratos这类框架省事，但它们默认注入大量全局状态（如logx、trace），和已有监控体系对接时得重写初始化逻辑
真正难的不是写一个能跑的 Go 微服务，而是让一百个服务在三年里持续低故障率运行——这时候 goroutine 的可控性、二进制的确定性、错误传播的显式性，才真正变成不可替代的约束条件。
