Go语言单一职责原则应用_Golang函数与包职责划分-Golang-PHP中文网

单一职责原则是为降低修改成本而设的实际防线：函数只做一件事且可准确命名，包按“同因变更”划分，接口小而具体、由调用方定义。拆分后各组件解耦，测试独立，变更影响可控。

go语言单一职责原则应用_golang函数与包职责划分

Go 里“单一职责”不是教条，而是为减少改一处崩一片而设的实际防线。它直接决定你改 RegisterUser 时会不会顺手把邮件模板、日志字段、数据库事务全翻出来修。

常见错误是把校验、保存、发邮件、打日志全塞进一个 RegisterUser 函数里。一旦邮箱服务下线或日志格式调整，这个函数就得动，哪怕用户注册逻辑本身没变。

拆法很简单：用 ValidateUser、SaveUser、SendWelcomeEmail、LogRegistration 四个独立函数替代
它们之间不耦合——SaveUser 不依赖 SendWelcomeEmail 的返回值，也不调用它
参数尽量窄：ValidateUser 只收 username 和 password，别传整个 *http.Request 或 context.Context（除非真需要）
测试时能单独覆盖每条路径，比如只测 ValidateUser 对弱密码的拒绝，不用 mock 邮件客户端

很多人误以为“用户相关代码都该在 user 包里”，结果把 User 结构体、HTTP handler、数据库 query、Redis 缓存逻辑全堆进去。结果缓存策略一改，整个包都要 retest。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

真正该放一起的，是那些“因同一原因变更”的东西。比如所有数据库操作（CreateUser、FindUserByID、UpdateUserStatus）才属于同一个变化原因——DB schema 或 driver 升级
所以更合理的结构是：model.User（纯数据）、repository.UserRepo（DB 操作）、service.UserService（业务编排）、handler.UserHandler（HTTP 绑定）
注意 repository 包不该 import handler，反之亦然；循环依赖是职责混杂最直接的信号
如果某个包同时 import database/sql 和 net/http，大概率它已经超载了

Go 没有继承，但有人写个 UserService 接口，塞进 12 个方法，然后所有实现都得实现全部——哪怕只用其中 2 个。这违反 SRP，也违背 Go 的接口哲学。

按使用方需要定义接口。比如邮件发送模块只关心 Send(to, subject, body string) error，那就定义 Mailer 接口，别硬塞进 UserService
让结构体通过组合实现能力：一个 user.Service 可以持有 mailer.Mailer 和 repo.UserRepo 字段，而不是自己实现所有行为
接口名体现职责：Storer（存）、Finder（查）、Notifier（通知），比 Manager 或 Handler 更精确
接口定义放在调用方包里（如 service 包定义 mailer.Mailer 接口），而非实现方（email 包），避免实现绑架契约

拆包不是为了整齐，而是为了降低修改成本。以下信号说明你正在接近合理边界：

go list -f '{{.Deps}}' ./pkg 输出里没有本不该出现的包，比如 handler 包依赖了 email/template 或 crypto/bcrypt
运行 go test ./... -run=^TestSaveUser$ 能秒过，且不启动 HTTP server、不连 DB、不发真实邮件
某次 PR 只改了缓存逻辑，git diff 只出现在 cache/ 目录，没碰 model/ 或 handler/
新人看 service/ 包，能快速说出“这里只协调，不落地；具体落地在 repo/ 和 mailer/”