单例模式中全局变量性能最优，sync.Once次之，懒加载最差；工厂模式推荐函数工厂以提升性能；依赖注入优先选择手动注入或Wire；选项模式宜用函数式选项。
Go语言的设计模式实现方式多样，不同实现对性能、可读性和扩展性影响显著。设计模式本身不直接提升性能，但合理选择实现方案能减少资源消耗、提升执行效率。以下是几种常见设计模式在Go中的实现方式及其性能差异分析。
单例模式：懒加载 vs sync.Once vs 全局变量
单例模式确保一个类仅有一个实例。Go中常见实现方式有三种：
-
懒加载 + 双重检查锁定：在并发场景下需配合
sync.Mutex
使用，每次获取实例都需加锁判断，性能较低。 -
sync.Once：Go标准库推荐方式，
Once.Do()
保证初始化仅执行一次，内部做了优化，开销小，适合高并发场景。 - 包级全局变量：在包初始化时创建实例，无运行时开销，性能最佳，但失去延迟初始化优势。
性能排序：全局变量 > sync.Once > 懒加载+锁。若实例初始化开销小，推荐使用包级变量；若需延迟初始化，
sync.Once是最佳选择。
工厂模式：函数工厂 vs 结构体工厂
工厂模式用于解耦对象创建逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 函数工厂：使用普通函数返回接口或结构体，调用开销极小，无额外内存分配，性能最优。
- 结构体工厂：工厂本身为结构体，可能包含配置或状态，灵活性高，但每次调用可能涉及方法查找和内存访问，略慢于函数工厂。
大多数场景下，函数工厂足够使用，性能更好。结构体工厂适用于需维护状态或配置的复杂场景，但应避免频繁创建工厂实例。
依赖注入：手动注入 vs 容器管理
依赖注入提升可测试性和解耦。
- 手动注入：通过构造函数或Setter传入依赖，无运行时开销，编译期确定依赖关系，性能最佳。
-
依赖注入容器（如Wire、Dig）：
Wire
是代码生成工具，编译期生成注入代码，运行时无反射开销；Dig
使用反射在运行时解析依赖，存在明显性能损耗，尤其在大型对象图中。
生产环境推荐
Wire或手动注入。避免在高性能路径使用基于反射的DI框架。
选项模式：可变参数 vs 函数式选项
用于构建复杂配置对象。
- 可变参数 + 结构体：易用但类型安全差，需类型断言，易出错且性能不佳。
-
函数式选项（Functional Options）：传入配置函数，类型安全，编译期检查，常见于标准库（如
net/http
）。虽有函数调用开销，但通常只执行一次，影响可忽略。
函数式选项模式在性能和可维护性上均占优，是Go社区主流做法。
基本上就这些。Go的设计哲学强调简洁和性能，实现设计模式时应优先考虑语言特性，如闭包、接口、组合等，避免过度抽象。合理利用编译期机制和最小化运行时开销，才能写出高效、清晰的代码。
