go微服务成败取决于服务边界、调用可控性与可观测性，而非框架选型；需强制grpc超时与服务发现、http客户端显式配置、proto契约化设计、全链路trace透传及健康探测前置。
Go 本身不提供“微服务框架”，所谓“Golang微服务框架”其实是开发者围绕通信、发现、治理等环节拼装出的一套工具链。真正决定架构成败的，不是用了哪个库，而是服务边界是否清晰、调用是否可控、失败是否可观察。
gRPC 客户端初始化必须带超时和 resolver
裸写 grpc.Dial("user-service:8080") 是线上事故高发点：下游卡死、DNS 缓存过期、连接池耗尽都会直接拖垮调用方。
- 所有
grpc.DialContext必须套context.WithTimeout，建议首跳设 300–500ms - 别硬编码地址，用
grpc.WithResolvers接入 Consul 或 etcd 的 SRV 记录解析器 - 加
grpc.WithKeepaliveParams防止长连接被中间设备静默断开
服务间 HTTP 调用不能依赖 http.DefaultClient
默认客户端没超时、没连接复用、没重试控制，一压就崩。哪怕只是内部服务间简单 GET，也得封装一层。
- 用
http.Client{Transport: &http.Transport{...}}显式配置 MaxIdleConns、IdleConnTimeout - 所有请求必须传入
r.Context()，并在 handler 开头做ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second) - 非幂等操作（如 POST）禁止自动重试；GET 可配最多 2 次重试，且需判断错误类型（
net.ErrClosed可重试，json.SyntaxError不可）
proto 文件定义要约束字段语义，不止是类型
很多团队只关注生成代码能不能跑通，却忽略 .proto 是服务契约——它决定了上下游能否安全演进。
- 必填字段用
syntax = "proto3";+optional显式声明，避免 nil panic - 枚举值必须带
UNSPECIFIED = 0;占位，防止新旧版本反序列化失败 - 不要在 message 里塞大 blob 字段（如 base64 图片），改用单独接口 + 签名 URL 下载
- 所有 RPC 方法加
google.api.http注解，方便grpc-gateway自动生成 REST 接口，避免两套逻辑不同步
可观测性不是上线后补，是启动时就埋点
没有 trace_id 的日志、没暴露 /metrics 的进程、没透传 context 的中间件，等于放弃诊断能力。
- HTTP 和 gRPC server 中间件必须注入
go.opentelemetry.io/otel的 propagator，保证traceparent头自动透传 - 日志用
zerolog输出结构化 JSON，固定字段含service、trace_id、span_id、http_status - 每个服务启动时注册
prometheus.NewCounterVec，至少覆盖 “rpc_total”、“rpc_error_total”、“rpc_duration_seconds” - 别等出问题才查，把
curl -s http://localhost:8080/metrics | grep rpc_total加进健康检查脚本
最常被跳过的其实是服务注册前的健康探测——Consul 或 etcd 不会替你判断服务是否真能处理请求。/health 端点返回 200 不代表数据库连得上、Redis 没满、gRPC server 已 ready。这块逻辑必须自己写，而且得在注册服务前执行。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
