Go本身不提供“微服务”内置功能，需通过服务拆分（按业务能力而非模块）、Consul注册（禁用localhost、用环境变量注入地址）、HTTP/JSON初期通信（gorilla/mux路由+统一handler签名+手动透传X-Request-ID）及可观测性（统一日志字段命名如trace_id、service_name）来实现。
golang 本身不提供“设置微服务”的命令或内置配置项——它没有 microservice.Enable() 这种东西。所谓“设置微服务”，本质是**用 Go 的标准能力 + 明确设计决策 + 若干关键工具链，把一个单体逻辑拆成多个可独立部署、通信、演进的进程**。
下面直奔实操重点：
怎么定义服务边界：别按模块切，按业务能力切
常见错误是建一个 user_service，然后把登录、注册、头像上传、密码重置、第三方绑定全塞进去。这叫“单体换壳”，不是微服务。
正确做法是识别限界上下文（Bounded Context）：
-
UserProfileService：只管展示型字段（昵称、头像、性别），不碰认证逻辑 -
AuthnService：只处理 token 签发/校验、MFA、登出，不存用户资料 -
AddressValidationService：只调第三方清洗地址，不参与下单流程
每个服务必须有自己独立的数据存储（哪怕只是单独 schema），且对外接口极窄——比如只暴露 ValidateAddress(ctx, req *ValidateRequest) (*ValidateResponse, error)。
怎么让服务能被发现：Consul 注册别写死 localhost
Docker 里写 http://localhost:8500 必挂，因为容器内 localhost 指自己，不是宿主机。
立即学习“go语言免费学习笔记（深入）”；
实操要点：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 用环境变量注入地址：
CONSUL_ADDR=consul:8500（Docker Compose 中consul是 service 名） - 注册时显式带健康检查路径：
Check: &consul.AgentServiceCheck{HTTP: "http://localhost:8080/health", Interval: "10s"} - 服务名只允许小写字母、数字、短横线；
user_rpc会注册失败，得改成user-rpc - 启动前用
etcdctl get --prefix ""或 Consul UI 确认节点是否真写进去了（路径通常是/services/或/go-zero/开头）
怎么通信才不踩坑：HTTP 和 gRPC 的真实分工
别一上来就上 gRPC。90% 的内部服务初期用 HTTP/JSON 更快、更直观、更好调试。
但裸写 http.HandleFunc 会迅速失控。推荐组合：
- 路由用
gorilla/mux（支持{id:\d+}路径约束），每个业务域（如user）建独立package，暴露RegisterHandlers(r *mux.Router) - 所有 handler 统一签名为
func(http.ResponseWriter, *http.Request)，别塞context.Context进参数列表 - 返回 JSON 前必须设头：
w.Header().Set("Content-Type", "application/json; charset=utf-8") - 跨服务调用时，
X-Request-ID必须手动透传：req.Header.Set("X-Request-ID", r.Header.Get("X-Request-ID"))
等接口稳定、调用量上升、开始出现类型丢失（int64 变 float64）或超时难控时，再收敛到 gRPC。此时注意：
- 客户端初始化必须加
client.WithInsecure()（本地开发没 TLS 证书） - 所有
client.Call()都要传原始ctx，不能用context.Background() - 传 metadata 用
metadata.AppendToOutgoingContext(ctx, "trace-id", id)，不是往 request struct 里塞字段
怎么让服务可观测：日志字段命名比用了什么库更重要
很多团队上了 zap + opentelemetry-go，结果 ELK 里搜不到 user_id——因为有的服务打的是 uid，有的是 userId，有的是 user_id_str。
真正关键的是统一字段语义：
- trace ID 字段名固定为
trace_id（不是traceId、X-Trace-ID） - 服务名字段名固定为
service_name（不是svc、app） - 所有日志结构体字段都小写+下划线，和 Prometheus label、ES mapping 对齐
- HTTP handler 入口第一行就从
r.Header.Get("X-Request-ID")提取并注入ctx，后续所有日志、下游请求自动携带
最常被忽略的点：链路 ID 在中间件里提取后，没塞进 context 就往下传；或者 downstream 请求头里漏了 X-Request-ID，导致整条链路在第二个服务就断掉。
