文件内初始化对象与结构体初始化：哪种是Go语言最佳实践？

你提到的两种模式本质是依赖注入式构造和全局单例对象的差异，下面直接拆解优缺点和适用场景：

一、你习惯的依赖注入模式（NewServer构造函数） #

先看你的实现：

type Server struct {
    config     util.Config
    store      db.Store
    tokenMaker token.Maker
    router     *gin.Engine
}

func NewServer(config util.Config, store db.Store) (*Server, error) {
    tokenMaker, err := token.NewPasetoMaker(config.TokenSymmetricKey)
    if err != nil {
        return nil, fmt.Errorf("cannot create token maker: %w", err)
    }

    server := &Server{
        config:     config,
        store:      store,
        tokenMaker: tokenMaker,
    }

    server.setupRouter()
    return server, nil
}

优点： #

• 可测试性拉满：单元测试时能轻松传入Mock版的store、tokenMaker，比如模拟数据库返回、伪造token生成逻辑，不用修改全局状态，测试用例互不干扰
• 依赖关系透明：从NewServer的参数就能直接看出Server依赖哪些组件，新人接手一眼就能懂
• 支持多实例：如果后续需要同时运行多个不同配置的Server（比如多租户、分环境测试），直接调用多次NewServer就能实现，不会有冲突
• 生命周期可控：在main里完全掌控初始化时机，比如先加载配置、初始化数据库连接，再创建Server，避免初始化顺序错误导致的panic

缺点： #

• 需要手动传递对象：比如在Gin handler里要访问Server的成员，得把handler绑定到Server结构体（server.router.POST("/", server.handleXXX)），或者通过Context传递，多了几步代码

二、博客中的全局对象模式 #

直接在文件内初始化全局变量（比如var globalServer = initServer()），其他模块直接访问。

优点： #

• 代码写起来快：不用层层传递对象，任何地方直接调用globalServer，省去依赖传递的代码

缺点： #

• 测试灾难：全局对象初始化后很难替换，多个测试用例如果修改了全局对象的状态，会互相污染，必须额外写清理逻辑，测试成本陡增
• 依赖关系模糊：其他模块直接用全局对象，不知道它依赖的config、store是怎么来的，维护时容易踩坑
• 无法扩展多实例：一旦用了全局变量，就只能有一个Server实例，后续业务扩展（比如多租户）直接卡壳
• 初始化时机不可控：全局变量在程序启动时就会初始化，如果依赖的配置还没加载、数据库还没连接，直接panic

三、该选哪种？ #

• 90%以上的生产项目：优先用依赖注入模式，这是Go后端开发的标准最佳实践，能大幅提升代码的可维护性和可测试性
• 小型工具/脚本：可以用全局对象模式，毕竟这类项目生命周期短、不需要复杂测试，便捷性优先
• 特殊单例组件：比如全局日志实例、全局只读配置，可以用全局模式，但要确保初始化时机正确，且状态不会被修改

内容的提问来源于stack exchange，提问作者Avinash Sah