拆单体前须统一go mod管理依赖，禁用子服务go mod init；http中间件需按服务定制；数据库连接池须独立配置；grpc调用需检查端口监听并加超时控制。
拆单体前先确认 go mod 已统一管理依赖
很多团队在拆服务时直接复制代码，结果各服务的 github.com/some/pkg 版本不一致，一跑就报 undefined: xxx 或类型不兼容。这不是架构问题，是模块管理没对齐。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有待拆出的服务必须用同一份
go.mod文件初始化（或至少共享replace和require约束） - 禁止在子服务里执行
go mod init重新生成模块名——应沿用原单体的 module path，比如example.com/platform，再通过子目录区分服务 - 验证方式：在根目录运行
go list -m all | grep your-service-name，确保没有重复或冲突的模块条目
http.Handler 拆分后别硬套全局中间件
单体里一个 logMiddleware 包裹整个 http.ServeMux 很方便，但拆成独立服务后，每个服务的请求路径、认证方式、超时策略可能完全不同。强行复用会导致日志错乱、鉴权绕过、或 context.DeadlineExceeded 频发。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 把中间件逻辑下沉到具体 handler 内部，或封装为可配置的函数，例如：
newAuthHandler(h http.Handler, cfg AuthConfig) - 避免在
main.go顶层用http.Handle注册通配路径；改用chi.Router或gorilla/mux显式声明路由边界 - 特别注意
Content-Type处理——单体可能默认接受application/json，但拆出的订单服务必须拒绝text/plain，否则 API 边界就模糊了
数据库拆分最易踩的坑：sql.Open 连接池没隔离
单体共用一个 *sql.DB 实例没问题，但拆服务后若仍让多个服务连同一个 MySQL 实例且共享连接池参数（比如 SetMaxOpenConns(10)），会出现某服务突发流量拖垮其他服务的 DB 连接。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个微服务启动时独立调用
sql.Open，并根据自身 QPS 设置专属连接池：db.SetMaxOpenConns(5)、db.SetMaxIdleConns(2) - 不要把
*sql.DB当成全局变量塞进 config struct 里跨服务传递——它不是线程安全的“配置”，而是有状态的资源句柄 - 验证方法：在服务启动日志中打印
db.Stats()，确认OpenConnections峰值不会超过预设值
本地调试时 grpc.Dial 失败，先查 localhost:port 是否真在监听
拆出用户服务后，订单服务调用 UserServiceClient 总是卡在 context deadline exceeded，但 curl http://localhost:8081/health 又能通——大概率是 gRPC 端口没暴露或被防火墙拦截，而不是证书或协议问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 启动服务时显式绑定
0.0.0.0:9090而非127.0.0.1:9090，否则 Docker 容器间无法互通 - 用
netstat -tuln | grep :9090或lsof -i :9090确认端口处于LISTEN状态，而非TIME_WAIT - gRPC 客户端初始化务必加
WithBlock()+ 超时控制，例如：grpc.Dial("localhost:9090", grpc.WithTransportCredentials(insecure.NewCredentials()), grpc.WithTimeout(3*time.Second))
服务化演进最难的不是写代码，是让每个服务真正拥有独立生命周期——从 go run 启动那一刻起，它就得自己管好依赖、端口、配置和错误传播边界。稍不注意，就会变成“披着微服务外衣的分布式单体”。
