go微服务落地需严守规范：必须用go modules独立初始化、显式指定依赖版本、禁用vendor；http选net/http+gorilla/mux或规范使用gin；强制服务发现与健康检查；所有goroutine须受context控制并设超时；强调接口契约与可观测性。
Go语言入门门槛低，但微服务落地时容易卡在“能跑通”和“可维护”之间。直接上框架、抄模板，大概率会掉进依赖混乱、服务间通信裸奔、配置硬编码的坑里。
Go Modules 是微服务项目的起点，不是可选项
所有服务必须独立初始化 go mod init，不能共用一个 go.mod。否则不同服务升级同一依赖（比如 grpc-go）时版本冲突，go build 会报错或运行时 panic。
- 每个服务目录下执行
go mod init github.com/yourname/user-service，模块名要唯一且带域名前缀 -
go get添加依赖时，明确指定版本（如go get github.com/gin-gonic/gin@v1.10.0），避免go mod tidy自动拉取不兼容的最新版 - 不要把
vendor提交到 Git —— 它会让 CI 构建变慢，且 Go 1.16+ 默认关闭 vendor 模式
HTTP 服务别只用 net/http，但 Gin 不是万能解药
net/http 足够写健康检查、简单路由；但加中间件（日志、鉴权、超时）、参数绑定、错误统一处理时，手写太累。Gin 确实快，但它的 Context 是隐式传递，调试时容易丢请求上下文，尤其跨 goroutine。
- 初学建议从
net/http+gorilla/mux入手：路由清晰、Vars(r)取路径参数直观、中间件链式调用易理解 - 若选 Gin，务必禁用
gin.DebugMode（设GIN_MODE=release），否则日志泄露敏感路径 - 所有 HTTP handler 必须显式设置
w.Header().Set("Content-Type", "application/json")，否则前端可能解析失败
服务发现不能靠 localhost:8081 硬编码
本地开发时写死地址没问题，但一上 Docker 或 K8s，服务 IP 动态分配，硬编码直接导致调用失败。Consul、etcd 这类组件不是“高级功能”，而是微服务的基础设施底线。
- 哪怕只用单节点 Consul，也要在服务启动时注册：
client.Agent().ServiceRegister(...)，并实现/health接口供 Consul 健康检查 - 服务间调用时，别用
http.Get("http://localhost:8082/users")，改用 Consul DNS 或 API 查服务实例：client.Health().ServiceNodes("user-service", nil) - Docker Compose 中，服务名（如
user-service）可直接当 host 使用，但这是 Docker 内部 DNS 的便利，不是通用解法
goroutine 泄漏比性能差更致命
微服务里大量用 go func() {...}() 处理异步任务（如发消息、写日志），但忘了加 context 控制生命周期，会导致 goroutine 积压、内存持续上涨、最终 OOM。
- 任何启动 goroutine 的地方，必须传入
ctx，并在函数内监听ctx.Done() - 数据库查询、HTTP 请求、RPC 调用，全部要带超时：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) - 用
pprof定期查/debug/pprof/goroutine?debug=2，看是否有数百个阻塞在select或chan receive的 goroutine
微服务不是堆技术，而是约束下的取舍——接口契约比代码漂亮重要，可观测性比功能多重要，服务边界比复用代码重要。这些点不在文档开头，但在第 3 次线上故障后，你一定会回来重读。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
