go微服务可维护性取决于接口边界清晰、依赖显式、变更局部化：用interface定义服务边界并置于被依赖方，初始化收口到newxxx()函数，错误处理用自定义类型+errors.is()，配置解耦为结构体传参。
Go 微服务的可维护性不取决于用了多少设计模式，而在于接口边界是否清晰、依赖是否显式、变更是否局部化。
用 interface 切割服务边界，而不是包名或目录结构
很多人把“分层”理解为建 handler、service、repository 三个包，但没定义接口，导致测试时只能打桩整个包，或者改一个 service 就得连带改所有调用方。
正确做法是：每个对外提供能力的模块，先写 interface，放在被依赖方（比如 user.Service 接口应定义在 user 包里），调用方只依赖这个接口。
- 测试时可直接传入 mock 实现，无需依赖 DI 框架或反射
- 更换数据库实现（如从 PostgreSQL 换成 DynamoDB）时，只要新
repository满足原有UserRepo接口，上层完全无感 - 避免循环依赖：两个包互相 import 具体类型会卡死，但若只 import 对方的
interface（且该 interface 定义在第三方包或本包内），就能绕过
初始化逻辑必须收口到 NewXXX() 函数，禁止全局变量或 init()
微服务启动时常见问题：数据库连接、Redis 客户端、配置加载顺序错乱；某处隐式调用 init() 导致环境未就绪就 panic；单元测试因全局状态污染而失败。
所有组件初始化必须显式、可控、可替换：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个核心组件（如
user.UserService）提供NewUserService(repo user.UserRepo, logger *zap.Logger)，参数全为接口或基础类型 - 主函数中按依赖顺序逐个构造，例如先
newDB()，再newUserRepo(db)，最后newUserService(repo, logger) - 绝不使用
var db *sql.DB全局变量，也不在init()里读配置或连数据库
错误处理统一用自定义错误类型 + errors.Is() 判断，不用字符串匹配
微服务链路长，下游返回 "connection refused"，中间层又包装成 "failed to call auth service: connection refused"，上游用 strings.Contains(err.Error(), "refused") 判断重试——这种写法一升级底层库就崩。
应该让错误携带语义和上下文：
- 定义
var ErrUserNotFound = errors.New("user not found")，并在业务逻辑中直接返回return user.ErrUserNotFound - 包装错误用
fmt.Errorf("validate email: %w", err)，保留原始错误链 - 判断时用
errors.Is(err, user.ErrUserNotFound)，不碰Error()字符串 - HTTP handler 中统一转成 status code：
if errors.Is(err, user.ErrUserNotFound) { http.Error(w, "not found", http.StatusNotFound) }
配置加载与热更新必须解耦，避免 viper.GetXXX() 遍地开花
直接在几十个文件里写 viper.GetString("db.host")，会导致：配置项改名时漏改、无法做类型校验、测试时难 mock、热更新后部分模块仍用旧值。
真正可维护的做法是：配置即结构体，加载即一次解码，后续只传值不查配置中心。
- 定义
type Config struct { DB struct { Host string `mapstructure:"host"` Port int } } - 启动时用
viper.Unmarshal(&cfg)一次性加载，检查cfg.DB.Host != ""等必要字段 - 把
cfg或其子结构体（如cfg.DB）作为参数传给NewDB()、NewUserService()等构造函数 - 如需热更新，监听变更后重建整个依赖树（例如新起 goroutine reload config → 构造新 service → 原子切换 handler 引用），而不是让各模块自己去拉新值
最常被忽略的一点：可维护性不是靠加抽象层堆出来的，而是靠每次修改都只动一个地方。当你发现改一个字段要同时动 handler、service、repo、migration、test 五处，那不是架构问题，是接口契约没立住——先补 interface，再谈其他。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
