在Golang项目开发中，单例模式可以保证某个结构体全局只有一个实例，依赖注入则能将实例的创建和使用分离，两者结合既能避免重复创建实例的资源浪费，又能降低模块间的耦合度，让代码更易维护和测试。
单例模式的基础实现
单例模式的核心是确保全局只有一个实例，并且提供一个全局访问点。在Golang中，最基础的实现方式是使用包级别的变量和sync.Once来保证实例只创建一次，避免并发场景下的重复初始化问题。
以下是一个简单的单例模式实现示例，定义了一个Config结构体，用来存储全局配置信息：
package singleton
import (
"sync"
)
// Config 全局配置结构体
type Config struct {
AppName string
Port int
}
var (
configInstance *Config
once sync.Once
)
// GetConfigInstance 获取Config的单例实例
func GetConfigInstance() *Config {
once.Do(func() {
// 初始化默认配置
configInstance = &Config{
AppName: "default_app",
Port: 8080,
}
})
return configInstance
}
依赖注入的引入
如果直接在业务代码中调用GetConfigInstance()获取实例，会导致业务代码和单例的获取逻辑强耦合，不利于后续修改和单元测试。这时候可以引入依赖注入，将单例实例作为参数传递给需要使用它的结构体，而不是在结构体内部主动获取。
我们定义一个Server结构体，它需要依赖Config实例来启动服务，通过构造函数注入Config实例：
package server
import (
"fmt"
"your_project/singleton"
)
// Server 业务服务结构体
type Server struct {
config *singleton.Config
}
// NewServer 构造函数，通过参数注入Config实例
func NewServer(config *singleton.Config) *Server {
return &Server{
config: config,
}
}
// Start 启动服务
func (s *Server) Start() {
fmt.Printf("服务 %s 启动，监听端口 %dn", s.config.AppName, s.config.Port)
}
结合单例与依赖注入的完整流程
在项目入口处，我们先获取单例的Config实例，然后将其注入到Server的构造函数中，这样就完成了单例和依赖注入的组合使用，既保证了Config全局唯一，又让Server和单例的获取逻辑解耦。
以下是main函数的完整示例：
package main
import (
"your_project/server"
"your_project/singleton"
)
func main() {
// 获取单例配置实例
config := singleton.GetConfigInstance()
// 修改配置（可选）
config.Port = 9090
// 将单例实例注入到Server中
s := server.NewServer(config)
// 启动服务
s.Start()
}
线程安全与注意事项
上面的单例实现使用了sync.Once，可以保证在并发场景下实例只会被初始化一次，是Golang中推荐的单例实现方式。如果单例的初始化逻辑比较复杂，也可以把初始化逻辑放在once.Do的闭包中，避免初始化失败导致的异常。
另外，依赖注入时如果单例实例需要被多个模块使用，只需要将同一个实例分别注入到各个模块的构造函数中即可，不需要每个模块单独获取单例，这样进一步降低了模块间的耦合度。
适用场景
这种模式适合以下场景：需要全局唯一的资源，比如数据库连接池、配置中心、日志组件等；同时希望这些资源的依赖和使用分离，方便单元测试和后续功能扩展。如果不需要全局唯一实例，或者实例的创建逻辑非常简单，也可以不使用单例，只使用依赖注入即可。