微服务不适合小团队和MVP阶段；单体架构更合适，因团队规模小、业务简单、日活低，微服务会增加运维与协作成本。
Go项目该用微服务还是单体？别看概念，先看团队和业务能不能扛住——小团队、MVP阶段、日活
什么时候该坚持单体：Go写一个能跑通的MVP
Go 的编译快、二进制小、HTTP 标准库够用，天生适合快速交付单体服务。比如一个后台管理+用户注册+订单查询的轻量SaaS工具，用 net/http + gorilla/mux + sqlx 写完打包成一个 ./admin-service 二进制，部署到一台云服务器上，连 Docker 都可以省。
- 典型结构就是
main.go启动所有路由，handlers/、services/、models/分目录，数据库连接池全局复用 - 事务靠
tx.Begin()+tx.Commit()直接搞定，不用 Saga 或补偿逻辑 - 调试时
dlv一 attach 全局变量、调用栈全在眼皮底下，没有跨服务链路追踪的开销 - 陷阱：别为了“将来可能拆”提前抽象接口、加 service mesh 注入点、搞多层 mock——Go 不是 Java，过度设计反而拖慢迭代
什么时候该考虑微服务：模块已稳定、团队已分组、DB已分库
不是代码量到了就该拆，而是当 user-service 和 order-service 已经由不同小组维护、使用不同数据库（MySQL vs PostgreSQL）、发布节奏不一致（用户功能周更，订单逻辑月审）时，拆才有意义。
- Go 微服务真正的门槛不在写服务，而在基础设施：你得有
consul或nacos做服务发现，否则http.Get("http://order-service:8080/create")就是硬编码 IP - 每个服务至少要带健康检查端点：
GET /health，否则网关（如traefik）无法自动剔除故障实例 - 别用 Go 自己实现服务注册——直接抄
hashicorp/consul/api示例，client.Agent().ServiceRegister(...)三行就能注册，但记得加DeferDeregister防止僵尸节点 - 常见错误：多个服务共用一个 MySQL 实例+同一 schema——这叫“分布式单体”，比真单体还难维护
Go 微服务里最容易被忽略的细节：日志、错误、超时
单体里 log.Printf 打印就够了，微服务里一条请求横跨 3 个服务，没统一 trace ID 就等于瞎子摸象。
立即学习“go语言免费学习笔记（深入）”；
- 必须给每个 HTTP 请求注入
X-Request-ID，用中间件塞进context.Context，所有日志都带这个字段，否则ELK查不到完整链路 -
http.Client必须设超时：&http.Client{Timeout: 5 * time.Second}，否则下游卡死会拖垮整个调用方 goroutine - 错误不能只返回
errors.New("failed")，要用结构化错误（如pkg/errors或go.opentelemetry.io/otel/codes），让网关能区分 400（参数错）和 503（下游不可用） - 别在服务间传原始 error 字符串——Go 的
fmt.Errorf("wrap: %w", err)保留堆栈，但 JSON 序列化时会丢，得用err.Error()显式提取
架构选择不是技术洁癖比赛。很多团队花三个月搭好 Istio + Jaeger + Prometheus，结果发现核心问题是 DB 查询没加索引、接口没做缓存——先把单体里的 SELECT * 换成 SELECT id,name，比纠结要不要上 gRPC 实在得多。
