我对设计模式的理解
单例模式：部分落后的面向对象语言特有的反模式，违反单一原则，一个类不仅要实现功能，还需要管理自己的唯一实例。Java 中已由 SpringBoot 解决了底层的垃圾活，如果需要自行实现单例我只会觉得这人的脑袋坏掉了。
大部分情况出自 Java 面试题，经典且无用的八股文，仅仅为了考察根本用不到的懒加载、指令重排。
对于更先进的面向对象语言很好解决，例如 kotlin 的 object ，js 的{}，跳过 class 这一步直接创造对象就行了。
至于 Go 呢，package 是单例，sync.Once 可以实现延迟加载。

工厂、建造者、原型模式：Java 有用的设计理念，但是 Go 没有继承/重载，只能写点似是而非的东西。
但作为面试题，这三个只比单例好一点，也几乎没有实际意义。

代理、装饰器模式：由于 SpringBoot ，在 Java 里它们是基础设施，是面试题应该重点考的东西，可以避免一些错误的使用方法。

适配器模式：非常好的理念，编程是在破旧的茅草屋上缝缝补补，拆东墙补西墙，适配器让各种屎山能成功运转起来，是一座丰碑。

很多设计模式我只在自己的玩具项目上尝试引入，确实有些是很好的理念，但工作中我不会自找麻烦。设计模式要为代码实现服务，如果使用了设计模式能少写代码，好写代码，那么是好的，可惜事实并非如此，绝大部分业务/场景的复杂度远达不到 Springboot 框架的程度，强行引入一个又一个设计模式不如去干点更有意义的事。

例如可以折腾下多平台聊天机器人之类的玩具，真心要写得好这些设计模式几乎都会用到。
正常的话是不应该过度使用设计模式的，Java 还好说，Go 去凑合设计模式是没苦硬吃。
如果真的对设计模式情有独钟，就多写点呗，23 种设计模式已经是三十年前的破烂了，要与时俱进挑战一下 62 种：
https://github.com/iluwatar/java-design-patterns