大厂用Go做微服务因其goroutine+channel+单二进制部署三件套在高并发、快迭代、云原生场景中比Java更省事、扛压、可控：goroutine初始栈仅2KB、用户态G-P-M调度降低切换开销，单二进制部署实现秒级启动与轻量镜像。
大厂用 Go 做微服务，不是跟风，而是因为 goroutine + channel + 单二进制部署这三件套，在高并发、快迭代、云原生落地的真实场景里，确实比 Java/Spring Boot 更省事、更扛压、更可控。
goroutine 为什么能撑住百万级并发连接？
不是“理论上可以”，是生产环境真在跑。Java 的 Thread 默认栈 1MB，Go 的 goroutine 初始栈仅 2KB，且按需动态伸缩。调度由 Go 运行时（G-P-M 模型）在用户态完成，不陷入内核——这意味着上下文切换开销极低。
常见错误现象：把 goroutine 当线程用，盲目起几万个却没配 runtime.GOMAXPROCS 或没设 buffered channel，结果协程卡死或内存暴涨。
- 启动成本低 ≠ 可无限滥用：单机 50 万
goroutine是常见上限，超了会触发调度器抖动 - 别用
go func() { ... }()闭包捕获循环变量——用显式传参，否则所有协程读到的是最后一个值 - 阻塞操作（如 HTTP 调用、DB 查询）必须加超时，否则一个慢请求拖垮整条 goroutine 链
为什么微服务上线要“一键 scp 就跑”？
Go 编译出的是静态链接的单二进制文件，不含 JVM、不依赖 libc 版本（除非调 Cgo），容器镜像体积常压到 15MB 以内；Java 镜像动辄 300MB+，光拉镜像就耗几十秒。
立即学习“go语言免费学习笔记（深入）”；
使用场景：K8s 滚动更新时，Go 服务秒级就绪；Java 服务常卡在 JVM 预热、类加载、GC 初始化阶段，冷启动延迟 >800ms。
-
CGO_ENABLED=0 go build -ldflags="-s -w"是生产构建标配：关 Cgo 避免 libc 依赖，-s去符号表，-w去调试信息 - 别直接
go run main.go测性能——它不走完整编译流程，结果无参考价值 - Dockerfile 里用
FROM scratch而非alpine，进一步减小攻击面（前提是没用 cgo）
gRPC + Protobuf 为什么成了微服务通信事实标准？
HTTP/JSON 虽简单，但序列化开销大、类型弱、调试难；gRPC 默认用 Protobuf 编码，二进制体积小、解析快、IDL 强约束，天然适配多语言互通。
性能影响：实测同等负载下，gRPC QPS 比 REST+JSON 高 3–5 倍，延迟低 40%+，尤其在字段多、嵌套深的请求体场景。
- 别把
.proto文件散落在各服务里——统一放api/仓库，用buf做 lint 和 breaking change 检查 - 流式接口（
stream）别滥用：客户端没处理好Recv()超时或服务端没控制Send()频率，容易引发内存泄漏 - HTTP/1.1 网关（如
grpc-gateway）只是过渡方案，别当主力——它把 gRPC 语义转成 REST，丢了 streaming 和 header 透传能力
真正难的不是写几个 goroutine 或编出个二进制，而是把 context.Context 透传到每一层、把 panic 收敛到 handler、把 metrics 打点嵌进 middleware、把 tracing context 注入 gRPC metadata——这些细节不落地，再好的语言特性也救不了线上事故。
