真正卡住微服务落地的是初始化依赖、跨包调用和proto定义三处；需通过go list分析依赖图，确保模块具备独立生命周期、连接池与配置，用接口隔离领域边界，client封装下游调用并集成服务发现，proto按服务粒度拆分且严格版本兼容。
微服务拆分不是起个新 repo 就完事，真正卡住落地的，是初始化依赖、跨包调用和 proto 定义这三处。
怎么判断一个 Go 模块该不该拆成独立服务
别看它叫 user 包就急着建 user-service。先跑一遍 go list -f '{{.Deps}}' ./cmd/main，画出当前 main.go 初始化时所有包的依赖图——如果 user 初始化强依赖 order.Repository 或共享同一个 *sql.DB 实例，那它现在还不是服务，只是个模块。
- 能拆的前提：该模块有自己完整的生命周期（启动/关闭 DB/Redis/第三方 SDK）、不与其他模块共用连接池、配置项可独立覆盖
- 常见错误现象：
user.Service直接调order.GetByID—— 这说明领域边界没划清，得先抽象出order.OrderReader接口，让 user 只依赖接口，再谈物理隔离 - 实操建议：用多
main入口演进，比如cmd/userapi/main.go（HTTP API 层）和cmd/usersvc/main.go（纯业务逻辑），共用同一仓库但编译为不同二进制，这是成本最低的起点
HTTP 调用下游服务时为什么不能硬编码地址
http.Get("http://order-svc:8080/v1/order/123") 这种写法在本地根本跑不通，上线后也扛不住节点故障或灰度发布。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 硬编码地址导致无法做超时控制、重试策略、熔断降级，链路追踪 tag 也串不起来
- 所有下游调用必须封装成 client 接口，例如
type OrderClient interface { GetOrder(ctx context.Context, id string) (*Order, error) } - client 实现里才用
http.Client或 gRPC stub；初始化交给 DI 容器（如dig）或构造函数链，绝不在 handler 里 new - 生产环境必须走服务发现：Consul +
go-micro/registry/consul，或 DNS SRV 记录；开发环境用localhost+ 端口映射，别写死 host
proto 文件怎么写才不会变成新的单点故障
把所有接口塞进一个 api/ 仓库，改个字段全链路发版——这不是微服务，是 RPC 单体。
- 每个服务只定义自己暴露的
.proto，user.proto只描述用户查询，不包含repeated Order字段 - 禁止
import其他服务的 proto；真要复用结构（如分页），抽成v1/common.proto，版本号独立管理，向下兼容策略写进 README - 字段增删必须向后兼容：
reserved 3;标记废弃字段，注释写明// deprecated since 2026-01, remove in v2.1 - 新增字段必须设默认零值：
int32 version = 4 [json_name = "version"];，否则旧 client 调用会 panic 报"proto: cannot parse invalid wire-format data"
最容易被忽略的其实是数据库边界：初期可以共用 PostgreSQL 实例，但必须用不同 schema 或 database，且严禁跨 schema join——运维迟早会找上门来。限界上下文不是画在白板上的概念，它直接决定你第一个 CREATE TABLE 该建在哪。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
