Service层是业务编排职责边界，须通过接口注入外部依赖、使用原生类型或domain struct、避免日志和协议细节，函数应单一职责、输入结构化、错误类型化，并按复用性决定逻辑归属。
Service 层不是包名，是职责边界
Go 里没有“Service 层”语法支持，它只是你对 service 包（或类似命名）下函数职责的约定：只做业务编排，不碰 HTTP、DB 驱动、日志框架等具体实现。很多人一上来就建 service/ 目录，却把 db.QueryRow、http.Post 直接塞进 UserServiceImpl.Create，结果测试写不了，换数据库改得到处都是。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有外部依赖（DB、Cache、HTTP Client、消息队列）必须通过接口注入，比如
type UserRepository interface { FindByID(id int) (*User, error) } -
service包里的函数参数和返回值只用 Go 原生类型或你定义的 domain struct（如User），绝不暴露*sql.Rows或redis.Conn - 别在 service 函数里调
log.Printf或fmt.Println—— 日志由 handler 或 middleware 统一打，service 只负责 return error
怎么组织 service 函数签名才不容易返工
常见错误是把 service 方法设计成 “一个函数干完所有事”，比如 CreateUserWithProfileAndNotify(ctx, req)，看着省事，但只要通知渠道从邮件换成站内信，就得改函数签名、改测试、改所有调用方。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 一个 service 函数只解决一个业务动作，命名用动词+名词，如
CreateUser、SendWelcomeEmail、ChargeOrder - 输入用明确的 struct，避免传一堆零散参数：
func (s *UserService) CreateUser(ctx context.Context, input CreateUserInput) (*User, error)，其中CreateUserInput是你定义的 struct - 错误返回统一用自定义 error 类型（如
ErrUserExists），而不是靠字符串匹配，方便上层 switch 处理 - 如果真要组合多个动作（比如注册+发邮件），用另一个更高阶的 service 函数来编排，而不是塞进
CreateUser
为什么你的 service 单元测试总在 mock DB 上卡住
错误现象：写了个 TestCreateUser，发现要 mock sqlmock + redisgomock + gomock 三套工具，测个创建用户花了 80 行 setup，还老因为 driver 版本升级挂掉。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
根本原因是你没把依赖抽象干净，或者 mock 粒度太细（比如 mock 某个具体 SQL 语句）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 只 mock 接口，不 mock 具体 driver —— 例如你定义了
UserRepository接口，测试时直接传个内存实现：memRepo := &memUserRepo{users: make(map[int]*User)} - 避免在 test 里出现
sqlmock.New、gomock.Controller这类框架关键词，它们是泄漏的抽象 - 测试 focus 在业务逻辑分支：比如邮箱已存在时是否返回
ErrUserExists，密码长度不足是否返回ErrInvalidPassword - 集成测试另开文件（如
service_integration_test.go），用真实 SQLite 或 in-memory Postgres，不放单元测试里
什么时候该把 logic 提到 service，什么时候该留在 handler
典型误判：把参数校验（如 email 格式、page 是否 > 0）全扔 service 里；或者反过来，把「扣库存并生成订单」这种明显跨资源操作留在 handler 里，导致 controller 越来越厚。
判断依据就一条：这个逻辑是否会被其他入口复用？
- 会被复用 → 必须进 service（例如「发短信验证码」被登录、注册、重置密码共用）
- 纯协议适配（如解析 query 参数、校验 JWT、转换 HTTP status code）→ 留在 handler
- 涉及多个 domain model 协作（如创建订单要查商品、扣库存、写订单、发 MQ）→ 必须进 service，且用事务控制
- 第三方回调处理（如支付平台 webhook）→ 单独建
callback_service，别混进user_service或order_service
最常被忽略的是：service 函数不该承担「请求生命周期管理」—— context deadline、trace 注入、panic recover 都该在 handler/middleware 层做完，service 只管执行和返回。
