微服务性能瓶颈常源于连接管理、协议配置与序列化细节：grpc需复用clientconn、nginx须正确配置http/2和grpc_pass、protobuf应预分配缓冲区并避免反射、超时必须透传而非截断、keepalive参数不可缺失。
微服务部署后网络通信变慢、超时增多、CPU占用异常升高，大概率不是代码逻辑问题，而是连接管理或协议配置没对——gRPC没复用连接、HTTP/2被Nginx降级、Protobuf序列化在热路径反复分配缓冲区，这些才是真瓶颈。
gRPC客户端必须复用*grpc.ClientConn，别每次调用都grpc.Dial()
每次grpc.Dial()会触发DNS解析、TLS握手、HTTP/2协商，耗时远超一次RPC本身。压测时QPS上不去、延迟毛刺多，八成是这个原因。
- 全局初始化一次
*grpc.ClientConn，注入到业务层或通过依赖容器管理 - 若需多地址（如不同环境），按目标地址缓存conn，而不是按请求新建
- 务必调用
conn.Close()在进程退出前，否则fd泄漏；但运行中绝不能每请求关一次 - 检查是否启用了
grpc.WithTransportCredentials()或grpc.WithInsecure()，混用会导致连接无法复用
Nginx反向代理gRPC时，必须启用HTTP/2且用grpc_pass，禁用proxy_pass
用proxy_pass http://backend会让gRPC退化为HTTP/1.1，失去多路复用和头部压缩，实测延迟翻倍、连接数暴涨。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 确认Nginx版本 ≥ 1.13.10（原生支持HTTP/2）且编译时含
--with-http_v2_module - server块中必须配置
listen 443 ssl http2，并开启ssl_http_v2 - location内用
grpc_pass grpc://backend，不是proxy_pass；后端upstream协议也得是grpc:// - 禁用
proxy_buffering off和proxy_http_version 1.1这类HTTP/1.1残留配置
Protobuf序列化在高频场景下成瓶颈？绕过反射，预分配+手动BinaryMarshaler
默认proto.Marshal()走反射，字段超15个、QPS >5k时GC压力明显，pprof常显示runtime.mallocgc占CPU 20%+。
- 用
github.com/gogo/protobuf替代官方protoc-gen-go，生成代码自带MarshalToSizedBuffer()和Size() - 对心跳、状态上报等小消息，直接实现
encoding.BinaryMarshaler，用binary.Write()写入预分配的[]byte - 避免在proto message里放
bytes大字段；若必须传二进制，客户端提前make([]byte, 0, 8192)复用底层数组 - 禁用
google.golang.org/grpc/grpclog的默认日志（尤其grpclog.Info），它内部会fmt.Sprintf整个message
context超时设置错一层，下游就雪崩
服务A调用B，A设了5秒timeout，B内部又用context.WithTimeout(ctx, 3*time.Second)，结果B只剩2秒可用——这不是预留，是截断。
- 下游RPC必须直接透传上游ctx，不重设deadline；仅在本地DB查询、缓存加载等**确定耗时模块**才套新timeout
- HTTP handler里拿到的
r.Context()，要原样传给gRPC client，别用context.Background()或context.TODO() - 跨goroutine传递ctx时，用
go func(ctx context.Context) { ... }(req.Context())，别漏参数 - gRPC服务端务必配
grpc.KeepaliveParams()，否则中间设备（如AWS ALB、Envoy）空闲60秒就断连，下次请求必重连
真正卡住性能的，往往不是算法或业务逻辑，而是连接怎么建、数据怎么编、超时怎么传——这些细节没对齐，再好的架构也会在上线后掉链子。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
