go不提供微服务管理能力，需依赖外部组件或kitex等框架；kitex需idl生成代码、显式注册中心；consul需ttl健康检查；必须透传context控制超时。
Go 本身不提供“微服务管理”能力，它只是实现微服务的编程语言；真正负责服务发现、负载均衡、熔断、配置下发的是外部组件（如 Consul、Nacos、Istio）或轻量库（如 go-micro、kratos、kitex）。直接用 Go 标准库写 HTTP 服务 ≠ 管理微服务。
用 kitex 快速生成带治理能力的 RPC 服务
kitex 是字节开源的高性能 Go RPC 框架，原生支持服务注册/发现、中间件、限流、重试。它不依赖 Istio，适合中小团队快速落地。
常见错误是跳过 IDL 定义，直接手写 handler —— 这会导致序列化不一致、跨语言对接失败。
- 必须用
thrift或protobuf写 IDL（如hello.thrift），再通过kitex命令生成代码：kitex -module github.com/your/app -service hello hello.thrift
- 注册中心需显式初始化：用
etcd时，传入registry.WithEtcdClient(client)，不是只配地址字符串 - 服务启动时默认不注册：必须调用
server.Run()前设置server.WithRegistry(registry)，否则服务上线但不可见
在 Go 中正确集成 consul 实现服务发现
很多项目用 hashicorp/consul/api 手动注册，但忽略健康检查机制，导致故障实例长期留在服务列表中。
立即学习“go语言免费学习笔记（深入）”；
Consul 的服务存活依赖 TTL 或脚本检查，Go 服务不能只注册一次就不管。
- 注册时必须传
Check字段，推荐用TTL模式：Check: &api.AgentServiceCheck{TTL: "10s"}，并在后台每 5 秒调用client.Agent().PassTTL() -
srv, _, err := client.Health().Service("user-srv", "", true, nil)中第三个参数true表示只返回通过健康检查的实例，漏掉会路由到宕机节点 - 不要复用
*api.Client跨 goroutine：它内部含未加锁的缓存，高并发下可能 panic
避免用 context.Background() 透传超时控制
微服务链路中，上游 timeout 未向下传递，会导致下游继续执行、资源堆积、雪崩。
Go 的 context 是唯一标准透传机制，但常被忽略或误用。
- HTTP 入口处从
req.Context()取 context，不要新建：ctx, cancel := context.WithTimeout(r.Context(), 800*time.Millisecond)
- 调用下游 gRPC 时，必须把 ctx 传入
client.Method(ctx, req)，而非client.Method(context.Background(), req) - 数据库查询、Redis 调用等 I/O 操作，统一用带 timeout 的 context，不要单独设
db.SetConnMaxLifetime()代替
真正的难点不在框架选型，而在上下文传播的完整性、健康检查的实效性、以及每个网络调用是否都受控于同一个 context —— 这些地方一漏，服务看着在跑，其实已经失去可控性。
