@qweruiop 是翻译的，还有其他各国语言。

@wogogoing #8 哪里有问题？ Go 保证一个 package 只会初始化一次，包内的变量是包级作用域的全局变量，全局唯一，这不就是天生的单例。 扩展阅读： https://stackoverflow.com/questions/1823286/singleton-in-go `Just put your variables and functions at the package level.` 这能够解决 99%使用场景，如果无法解决，参考排名第一的回答。

应该是大脑被 java 造成了永久性损伤

大脑被 java 污染后, 再写别的语言, 容易抹黑人家

看到前面几楼都在吐槽用设计模式污染 Go ，确实不能照搬，Go 有自己的惯用法（ idioms ），好的代码不是设计模式堆砌出来的，而是解决实际问题、可读性强、易于维护的代码。

只写 java 的是这样的，建议也多看看其他语言，所谓的设计模式，在现代的编程语言中，很多都内化成语法了，举几个例子： 策略模式：一等函数公民(js/ts)，匿名函数 (c#), 类型类（ scala ） 构造者模式：case class (scala), record(jdk 17), data class(kotlin), dataclasses/pydantic (python ） visitor 模式: 代数数据类型 (rust), sealed trait + 模式匹配 (scala) 单例模式: 语法关键字支持（ scala/kotlin ）, 类本身就是 (ruby) Decorator 模式：Decorator 注解(python)

引用下 https://refactoringguru.cn/design-patterns 的一段话： 设计模式自其诞生之初似乎就饱受争议， 所以让我们来看看针对模式的最常见批评吧。 一种针对不完善编程语言的蹩脚解决方案 通常当所选编程语言或技术缺少必要的抽象功能时， 人们才需要设计模式。 在这种情况下， 模式是一种可为语言提供更优功能的蹩脚解决方案。 例如， 策略模式在绝大部分现代编程语言中可以简单地使用匿名 （ lambda ） 函数来实现。

设计模式是一种经验总结，属于应对特定问题的一般策略。实际上就算你一点设计模式不懂，一样能写出能用的代码，只是可能比较复杂容易出错，或者看起来没那么简洁易懂。当你反复遇到相同的问题时，很有可能自己重新发现并总结出某种设计模式。或者说你可能早就在用各种设计模式了，只是没有总结成特定的名词而已。 但所谓的设计模式毕竟是经验总结啊，也就是说它是有适用范围的。不能因为手里拿着设计模式的锤子，就看什么都是钉子。不同的编程语言差别很大，解决相同问题的经验是完全不同的，甚至在一种语言中的常见问题在另一种语言中甚至不存在。 举个例子，就拿参数传递来说，Java 因为不支持命名参数但支持重载，所以总结出了 builder 模式，而 Go 因为没有重载和构造函数，所以形成了函数式 Options 的习惯写法。非要 Go 用 builder 模式或者 Java 写函数式 Options 不是不行，只是没必要。 再比如楼上提到的装饰器模式，Java/C++ 这种常用是因为它们的 OOP 都是基于继承的，在不修改原始类的情况下动态增加新功能是比较复杂的，装饰器这个写法可以避免继承爆炸。换到 Go 里面正经人谁用装饰器啊？ Go 的 OOP 是基于组合的，简简单单嵌入 struct 不就可以了。 当然面试八股确实喜欢考这些东西，但属实没必要把设计模式当作编程学习的目标。

写 java 写的

@Ketteiron 发现新大陆