@lesismal 或者可以关注文章底部公众号，不喷不怼聊一聊也未尝不可!

@lesismal
兄弟还是你年纪大，你稳重，记得最开始你提的问题我也安静的思考，并且有找相关文章才给你的回复，锤子的例子就是设计模式相关文章 https://refactoringguru.cn/design-patterns 提出的：

但是可能思想觉悟没你高吧，或者就是你理解有什么误区。

“如果你只有一把铁锤， 那么任何东西看上去都像是钉子。”
这个例子的意思是：设计模式不当的使用会给初学模式的人们带来困扰： 在学习了某个模式后， 他们会在所有地方使用该模式， 即便是在较为简单的代码也能胜任的地方也是如此。

你直接评论下面这样：
“所以手持臃肿的铁锤的人就是那么喜欢臃肿的钉子”
“如果能只在自家臃肿就好了，放过那些新手，免得把 go 社区更多小白也整成臃肿的了。”
“另外，中了臃肿的毒的人，可能根本不知道自己中毒了。”

-- 这可能就是你所谓的平和心态，还有可能就是你说的“不要那么在意面子，太在意面子”，或者可能就是你理解的误区导致你直接开喷吧！

“最后，既然写文章发出来了，就要接受你的受众的反馈，既有正向的又有负向的，零差评是几乎不可能的事情”
-- 还有，这个我很认同啊，楼上很多人说案例比喻不准确，我接受了啊，人家是有理有据的评价文章内容的，没毛病，技术的碰撞才能产出更好的技术。但是你这确实有点偷换概念， 不说主题了吧，就事儿论事，你玩什么边车呢？

还有上面的举例属实吓人：
“一把杀过人的普通菜刀赠送给邻居，邻居不会愿意要，觉得不吉利，是不是应该强调菜刀只是道具跟杀人没关系？”
这种例子感觉不太妥当，有失风度了！

还有说你是“老中医”，确实是我考虑不周，但是你张口闭口的“中了臃肿的毒” “自己中毒”，不得不让我去遐想你的专业方向和思维逻辑了。

行了，兄弟，我写我的设计模式，你聊你的 go 和设计模式冲突的问题吧，这个撕逼我感觉再聊下去就有点滚刀肉了。
有机会还想讨论可以加个微信探讨下技术问题，

@sheepzh
@lesismal

这就好比买了份盒饭去路边吃，忘记拿筷子了，只能拿一个泡面叉子吃。那怎么地让别人看见了就认为是崇洋媚外了么？
重点是吃饭啊，兄弟~，你管我用啥吃呢？
文章也是，重点是讲述生成器模式啊，兄弟~。讲的是生成器模式，又不是讲计算机语言语法！

真的是，看球不看球，光去数人头。

1.全文上下 我也没有 引导读者用设计模式去搞 go 的字样吧？

2.我也不是标题党，标题也没有说写成 “用 golang 实现生成器模式” 吧？

我 tm 写文章的时候压根就没想过， 文章内容和案例 demo 的技术栈是否冲突的问题？

@lesismal

@sheepzh
@no1xsyzy
行了 兄弟们，我服了， 你们赢了，都是战争贩子！
写文章的意图是介绍设计模式，重点是设计模式。
你们却开始说别拿设计模式搞 go，真无语！
我要是只会 go 还不能发文章咯？
我要是只用 go 发文章就成了 那个话密的老中医口中的『你写你的，我认为不好的我就提出来，不让某个观点独霸市场。』 咯？

行，都是茬的！

对了还有那个话密的老中医，感谢在评论中带个私活，活儿不错！！ 君 x 子 r 之举！

@lesismal 感谢大篇幅回复 + 推文讲解！

我不是搞哲学的，解释不清楚，有兴趣的话可以到某乎上去看下，也不要再误解这句话
-- 最开始我以为你是搞医学的，差点给我看出毒来！

文章主体包括楼主后续的回复，其实都是非常认可文章内容
-- 思维逻辑可能正确，但是感觉主观意识略强，`差点给我整的以为我就是要推广设计模式呢` 恐怖！

另外，不管楼主安利不安利，我要安利：keep go clean, keep it simple stupid.
-- 现在我有主观态度了： 爱看不看，话太密！ 你写 go，不能证明你可以代表所有 goer~

@jiayong2793 哦，学习了，感谢！

@jiayong2793 纯属虚构哈，只是感觉这种模式在正常生产环境不是很常见，如果去哪现实生活中什么盖房子，造车 balala 的比喻肯定恰强，但是感觉再转化到代码场景中也需要成本，所以想了一个稍微贴近业务代码场景的例子。

@lesismal 可能文章写的比较粗糙哈，你可能理解的不太清楚或者主观意识太强。

这个文章重点是介绍设计模式，而不是安利谁要干什么，没有个人观点的输出昂！

还有，感觉 存在即合理，知 和 行 冲突么？ 没有人能控制你拿铁锤去砸哪个钉子。

最后，写好文章，撸好代码就挺好。真学不会业界大佬这样 瞧病把脉，银针验毒啥的。

@yuancoder 确实比较好理解，刚开始看生成器这个模式的时候也感觉很冗余，想了半天才想到一个稍微符合场景的例子，电脑报价。。。。发文的目的是总结下啥是『生成器模式』。

@Jirajine 我写的 java 代码量真的没有 go 多 - -，可能是设计模式太多用于 java 了吧

@lesismal 如果只有一把铁锤， 那么任何东西看上去都像是钉子。设计模式的争议缺失挺多的，感觉还是看个人代码风格。

@AlexChing 可能都关注公众号去了吧！ 哈哈 卷了~

@anxn 哎呀，我记得 markdown 的代码块中我设置 golang 语法了，go 语言标签怎么加。。。

分库是为了做资源隔离，当然复杂度提高肯定会有异常的风险，这个就要看性能和稳定的取舍了。

分表这个可能理解的不及你深刻哈，但是"根本没办法找到一个合理的分表依据"，这句话不太认同，系统设计之前要基于业务和数据分析，为什么就没办法找到合理的分表依据呢？ hash 分表是否数据均匀也要看数据量级和 hash 的字段是否均匀，目前看我经历过的分表几乎都是均匀分配的。如果谈到"冷热数据"，可能我写的文章太粗糙，没表达请求，按照 Range 的方式是可以实现大部分场景冷热分离的。

最后我认可你表达的复杂度提高，稳定性可能会下降的理论，相信你有 cover 单表过 N 亿的实力！

坚持沉淀知识点，持续输出，看到评论的你，感谢关注公众号！

@jorneyr 嗯啊，是有读写锁的。Inert Fill 是私有方法，上游是 Take 方法调用，在 take 中有做锁，全部代码没有贴出来，可以去看源码哈。https://github.com/xiaoxuz/limiter

@Yumax 感谢大佬支持~

@justrand 嗯啊, 不过个人感觉阅读清单中网页保存的过多也成垃圾箱了, 还是需要一个事件来驱动你 review 某个网页，所以加了一个自定义提醒的能力

PHP Fatal error: Call to a member function find() on a non-object in /Library/WebServer/Documents/zhihu/zhihu-php/zhihu/user.php on line 408

页面有 a 元素啊,为什么会 fatal 。 @ahonn 开发中遇到过没