svc 到底装了啥？要不要一直传？util 怎么用？

「所有上下文依赖都存进 svc」—— 这句话是错的

关键在于区分两件事：进程级共享依赖 和 请求级上下文数据。它们归宿完全不同，svc 只接前者。

svc 里到底存了什么

一句话：所有「进程启动时建一次、之后所有请求共享复用」的有状态依赖。下面是一份典型的 ServiceContext。

type ServiceContext struct {
    // 1. 配置：从 etc/xxx.yaml 读进来，全局只读
    Config   config.Config

    // 2. 数据库：连接池建一次，所有请求共用
    DB       *gorm.DB

    // 3. 缓存：redis 客户端，单例
    Redis    *redis.Redis

    // 4. 内部 RPC 客户端：goctl 生成的 stub，带 etcd 发现
    UserRpc  user.User
    OrderRpc order.Order

    // 5. 外部 HTTP 客户端：httpc，自带超时+熔断
    PayHttp  httpc.Service

    // 6. 消息队列生产者 / 消费者
    Producer kq.Producer

    // 7. 自定义业务 service（把一组依赖打包，见下文 util 章）
    OrderUtil *util.OrderUtil
}

svc 是不是「从上到下一直传递、一直传递」

是传递，但不是「每次都重建」——它从头到尾只有一个实例，靠指针从上往下一级级传引用。开销几乎为零。

// ① main：只建一次
func main() {
    var c config.Config
    conf.MustLoad(*configFile, &c)
    svcCtx := svc.NewServiceContext(c)   // ★ 唯一实例

    server := rest.MustNewServer(c.RestConf)
    defer server.Stop()
    handler.RegisterHandlers(server, svcCtx)  // 引用往下传
    server.Start()
}

// ② handler（goctl 生成）：接收并保存引用
func NewLoginHandler(svcCtx *svc.ServiceContext) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        l := logic.NewLoginLogic(r.Context(), svcCtx)  // 再往下传
        resp, err := l.Login()
        httpx.WriteJson(w, resp, err)
    }
}

// ③ logic：把指针存到结构体字段，业务里直接用
type LoginLogic struct {
    logx.Logger
    ctx    context.Context
    svcCtx *svc.ServiceContext   // ★ 只是个指针，零拷贝
}
func NewLoginLogic(ctx context.Context, svcCtx *svc.ServiceContext) *LoginLogic {
    return &LoginLogic{Logger: logx.WithContext(ctx), ctx: ctx, svcCtx: svcCtx}
}
func (l *LoginLogic) Login() (*types.LoginResp, error) {
    u, err := l.svcCtx.UserRpc.GetUser(l.ctx, &user.GetUserReq{...})  // 直接用
    ...
}

util / tool 这种地方，想用 svc 咋办

这是真实项目里最高频的困惑：logic 能拿到 svcCtx，可我的工具函数在 internal/util 里，它又没被传进来。三种正解 + 一个反例。

解法 A —— 传窄依赖（推荐起步）

// internal/util/sms.go —— 只认它需要的依赖，不碰 svc
package util
func SendCode(client sms.Client, phone, code string) error {
    return client.Send(context.Background(), phone, "您的验证码："+code)
}

// internal/logic/loginlogic.go —— logic 有 svcCtx，把具体依赖传进去
resp, err := util.SendCode(l.svcCtx.SmsClient, phone, code)  // 只传 SmsClient

解法 B —— 接口解耦，杜绝循环依赖

// internal/util/order.go —— util 自己定义接口，不 import svc
package util
type Querier interface {          // ★ 接口在 util 侧
    GetPrice(ctx context.Context, id int64) (int64, error)
}
func CalcTotal(q Querier, items []Item) (int64, error) {
    for _, it := range items { p, _ := q.GetPrice(...) ; ... }
}

// logic 里：svc 里的 *gorm.DB / RPC 只要实现了 Querier 就能传
total, _ := util.CalcTotal(l.svcCtx.DB, items)  // 只要 DB 满足 Querier

解法 C —— 升级为 struct service（强相关的一组工具）

// internal/util/order_util.go
type OrderUtil struct {
    db  *gorm.DB
    rpc order.Order
}
func NewOrderUtil(db *gorm.DB, rpc order.Order) *OrderUtil {  // 构造时注入
    return &OrderUtil{db: db, rpc: rpc}
}
func (o *OrderUtil) CloseExpired(ctx context.Context) error { ... }

// svc 里 new 一次，挂到 ServiceContext，logic 直接用
// svc/servicecontext.go:
OrderUtil: util.NewOrderUtil(c.DB, c.OrderRpc),

// logic:
err := l.svcCtx.OrderUtil.CloseExpired(l.ctx)

三个问题的答案，一句话版