Golang微服务最稳妥路径是先单体、再抽shared模块、最后按业务拆分；必须先重构internal/shared，统一配置、日志、错误、DB等基础能力，否则易陷“伪微服务”陷阱。
微服务不是一上来就拆的，Golang项目最稳妥的演进路径是：先用单体结构跑通核心业务，再把配置、日志、错误处理这些“所有服务都要用”的能力抽成 shared 模块，最后按业务边界切分服务——跳过这步，90% 的团队会掉进“伪微服务”陷阱：代码拆了，但配置散落、日志格式不一、启动逻辑重复、热更新失效。
从单体到可拆分：为什么必须先重构 internal/shared？
很多团队一上来就建 user-service、order-service 目录，结果三个月后发现：每个服务都自己写一遍 loadConfigFromYAML()、自己拼 log.With().Str("service", "xxx")、自己实现健康检查路由。这不是微服务，这是“复制粘贴分布式”。
真正该最先动刀的是项目根目录下的 internal/shared：
-
config模块要能统一加载 Consul + 本地 fallback，支持版本号、变更通知、回滚快照 -
logger必须封装zap.SugaredLogger并预设 trace_id 字段，禁止任何服务直接 import zap -
errors要提供带 HTTP 状态码、错误码前缀、上下文注入的封装，比如errors.NewBadRequest("invalid user_id") -
db不是简单封装 gorm，而是定义DBTX接口 + 统一连接池参数 + 自动迁移开关
没做完这些，拆服务就是在给运维埋雷。
立即学习“go语言免费学习笔记（深入）”；
服务拆分时，第一个被误判的边界：用户认证
几乎所有项目都会最早拆出 auth-service，但多数人立刻就错了：把 JWT 签发、OAuth2 回调、密码重置、短信验证码全塞进去。结果是它既慢（依赖短信网关）、又重（要连用户库查 profile）、还难测（涉及第三方回调）。
更合理的做法是分两层：
-
authn-service：只做 token 签发/校验/refresh，数据完全内存化或用 Redis，不碰任何业务数据库 -
identity-service：管用户注册、资料、多因素、社交登录，和user-service共享用户主数据（通过事件同步，而非直连）
混淆这两者，会导致 auth 变成系统瓶颈，且每次改登录流程都要牵连订单、支付等服务。
配置热更新为什么总失效？关键在初始化顺序
常见错误现象：consul kv 改了配置，服务日志里显示 “config updated”，但 db.MaxOpenConns 还是旧值，HTTP 超时也没变。
根本原因不是监听没注册，而是：配置值被读进 struct 后，就固化在 service 实例里了。比如：
type UserService struct {
db *sql.DB
timeout time.Duration // ← 这个字段初始化后就再也不看了
}
正确解法只有两个：
- 所有运行时可变参数（超时、重试次数、开关）必须通过函数参数传入，而不是存在 struct 字段里
- 数据库连接池等底层资源，要监听配置变更事件，触发
db.SetMaxOpenConns()等原生方法，而不是重建 DB 实例
否则所谓“热更新”，只是刷了一行日志而已。
最容易被忽略的点是：配置治理不是技术选型问题，而是启动流程重构问题。你得让 main.go 里只剩三行：初始化 shared、启动服务、等待信号。其余所有“读配置→建 logger→连 DB→注册 consul→启动 HTTP server”的链条，必须收进 shared/bootstrap 里统一调度。没做到这一步，演进就只是目录 rename 而已。
