Go微服务必须在初始化、依赖注入、错误处理、接口契约等环节建立约束，否则越拆越难运维；需封装Run函数支持上下文退出、结构体实现http.Handler统一中间件、分离gRPC注册与实现、多源配置校验及分层错误日志。
微服务不是把单体拆成一堆 main.go 就算完事——Go 项目若没在初始化、依赖注入、错误处理、HTTP/GRPC 接口契约等关键环节建立约束，服务越拆越难运维。
服务启动必须封装为可测试的 Run 函数
硬编码 http.ListenAndServe 或直接调用 log.Fatal 会让单元测试无法控制生命周期，也无法模拟启动失败场景。
- 把服务启动逻辑抽到带上下文和错误返回的函数里，例如：
func (s *Server) Run(ctx context.Context) error - 所有监听端口、注册路由、启动 gRPC server 都应在该函数内完成，并支持通过
ctx.Done()安全退出 - 避免在
init()或包级变量中做任何副作用操作（如连接数据库、加载配置），否则无法在测试中重置状态
HTTP handler 必须统一用 http.Handler 接口，禁用裸 http.HandlerFunc
裸函数难以注入中间件、日志、指标、超时控制，也导致 handler 单元测试只能靠黑盒请求模拟。
- 定义结构体实现
http.Handler，例如：type UserHandler struct { svc UserService } - 在
ServeHTTP方法中统一处理 panic 捕获、request ID 注入、trace 上下文传递 - 路由注册时不写
http.HandleFunc("/user", userHandler)，而是http.Handle("/user", userHandler) - 禁止在 handler 内部直接调用
os.Exit或log.Fatal—— 错误应由上层统一响应格式化
gRPC server 必须显式分离 RegisterXxxServer 和实际 service 实现
把业务逻辑塞进 UnimplementedXxxServer 的嵌入结构里，会导致接口膨胀、测试耦合、无法替换底层 transport。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 定义独立 service struct，例如：
type UserService struct { repo UserRepo } - 在启动时才调用
pb.RegisterUserServiceServer(grpcServer, &UserService{...}) - 所有 RPC 方法必须返回标准
error，且仅用status.Errorf构造错误，不拼接字符串或返回自定义 error 类型 - 禁止在 service 方法里直接操作
context.WithTimeout—— 超时应由 gateway 或 client 控制，server 只响应
配置加载必须支持多源合并与运行时校验
只从 config.yaml 加载配置，上线后改个端口就得发版；不校验必填字段，服务启动就 panic，但错误信息不明确。
- 使用
github.com/spf13/viper，按顺序绑定：环境变量 > CLI flag > config file > 默认值 - 所有配置 struct 必须带
validate:"required"tag，并在Run前调用validator.Struct校验 - 数据库连接串、Redis 地址等敏感字段，禁止硬编码默认值（如
"localhost:6379"），必须显式报错缺失 - 配置 struct 字段名用
CamelCase，对应 env var 全大写加下划线（如DB_HOST→DbHost）
最常被跳过的其实是错误分类：不是所有 err != nil 都该打 ERROR 日志——客户端参数错误要打 WARN，上游超时要打 INFO 并带 traceID，数据库连接失败才是 ERROR。这点不统一，告警就永远分不清是 bug 还是临时抖动。
