以上所有打字直到现在，我确实心里没什么波澜，算是平和的。
中毒这种说法是因为早年也跟不少 cpp 语言党聊过太多了，cpp 中毒太深的人过度玩弄语法语义和各种特性，cpp 里也有不少乐于搞设计模式的，一个单例能搞出 6 种还是 8 种实现。然而实际的架构设计、工程设计、算法设计、结构设计却不到位，导致日常夸夸其谈，项目问题不断。
这些多年撕得多得出的结论，而且也因为撕得多，所以早就平和了。

就像无法叫醒一个装睡的人，执着于语言特性、设计模式的好多人，也难回头，所以我称之为中毒。
经济学上讲，是因为“沉没成本效应”。在程序员这种职业上体现出来就是：自己花了不少功夫在某些知识上，舍不得承认这些知识的无用，并且继续对它学习研究，从而遮了眼、阻碍了自己的提升。
就比如设计模式吧，@no1xsyzy 见识广博，#21 里已经提到过了，设计模式之父自己都承认实际效果并不那么好。你再掰开了揉碎了仔细思考，真正有用的一些设计模式，比如观察者 /发布订阅，这种总结出来确实不错，但是大多数的设计模式真的未必有用，反倒是误以为宝贝的人，反复琢磨把玩、浪费了很多时间。比如单例模式，除了 java 这种一切皆类、必须通过实现单例或者直接 static 变量（不方法不优雅）才能使用这个公共变量的方式，其他语言基本都是一个公共变量就完事了，最多再加个显示的初始化或者作为函数返回值，让调用的方式看上去有一点虚伪的逼格而已。再比如工厂系列，最初知道这竟然是一种设计模式的时候，我都不好意思笑，多自然的一个事情，构造函数写舒服点就是工厂系列，非要整个单独的 createXX 之类的也行，设计模式之父自己都承认了一些事（我没去考证真假，但从设计模式实际的效用上讲，我觉得他应该承认过），我们大众何苦为难、作践自己呢。。。

设计模式和 go，我这么多认真回复，我觉得是“买椟还珠”，你作为卖家拿设计模式当个珠，用 go 的 demo 的盒子把它装里面了，而我是为了 go 这个盒子而来，真没 care 过设计模式

甚至于面向对象，大概 1996 年 cpp 标准委员会那帮老头子们开会就在聊“面向对象被社区滥用了呀”

再说点设计模式和面向对象的问题。社区已有的积累，可以继续吃老本，比如企业级、电商之类的，尤其是 java
但是良好的 OO 抽象体系也好、易扩展也好，在面对高速发展、快速迭代的产品和需求面前都不那么好使：
面向对象的鸭嘴兽问题，使得在很难预期大部分未来需求前提下，无法完美抽象、只能做到当下的抽象、无法做到未来的易扩展，设计模式同样，那些以为现在这样有哪些好处，未来可以怎样易于修改的好处，当不确定的未来真正到来的时候，很难发挥出其预期的优势，反倒可能因为早期的臃肿设计导致后续的修改难度更大。
真正有效的方案是进行阶段性重构。如果团队业务更新太快、疲于奔命，阶段性重构的频率就要降低、周期就要拉长，就得等到长时间日积月累后毕其功于一役。
今天为了以后易扩展做了很多更复杂的设计，明天可能因为非预期内的变化导致修改难度更大。所以像 go 这种不重语法糖特性和模式，反而专注于让事情简单化的语言，却成了工程性更好的选择

你应该能够从 go 语言本身感受到并且再深入思考一些：为什么 go 不天然面向对象？也不重设计模式？也不在意那些花哨的语法糖？
go 已经是站在那些以往优秀语言的巨人肩膀上，如果那些东西真的那么好，难道 c 爹和 rob pikez 这些老头子是老糊涂了？——这帮老头子们真的是老中医，切脉稳准狠，开出了 go 这副方子，让我一副药下肚，码欲大增、秀发得保，虽老矣，为心所愿之代码，尚可稍废寝食

然后我的疑问来了，既然用 go 了，你的意思好像又说你只写 go，那是谁带你跑偏去研习设计模式的？
把你引入歧途的人，是人性的扭曲还是道德的沦丧。。。你得喷他啊顺便把他也带回正轨。。。