并发量大的时候，基于标准库的 net.Conn 还是消耗很大。7 、8 年前记得国外有个团队单机 50w 连接推流，内存、调度成本还是很高
去年我自己的异步框架功能基本完善后，也琢磨支持下流媒体的然后不用每个连接一个协程去循环读了，可以节省太多协程数量、内存、gc ，都可以变得可控，但是我自己暂时没那么多时间精力搞这一大套、得看以后有没有适合的时机了。如果作者有兴趣可以试下搞套异步的

PS ，阿里系开源真是各种 KPI 烂尾，之前看他们有人出了个 livego ，代码感人，低级错误、连 panic 都没处理好稍微测试了下就宕机了，本想 pr 修复下，但是看已经烂尾了所以没再关注了

楼主这个，我之前就有关注过，加油！

生活就是这样子操蛋，同情楼主+1

@victor

外层有其他反代、中间件等设施做中转是可以交给其他基础设施处理。

但是 client 直连 go server 的，还是需要注意。比如用 go 做的基础设施

《喜剧之王》

某站上的那些凄凄厉厉声也是让人久久不能释怀的

半尺码克十万起，线上业务一百加

@hello2090
#22 也就写习惯了 CURD 简单逻辑的不太纠结这些。如果真都不用纠结，世间岂不早就被 c/cpp 一统江湖了

支持，java 届的人间清醒。
ps：总有很多巨婴程序员觉得 go 没有这不行、没有那不行，其实都是常年写逻辑的你自己不行

@RedisMasterNode
第一，这与跟风完全无关，我不是因为 rsc 开贴而跟风，我自己的工程结构都是自己设计。
既然说到跟风，你有没有思考过哪种人擅长跟风？自己的设计能力不足、缺少判断力的人，才经常跟风，工程结构这种事情涉及到一定的设计审美能力，但还不至于是难度很大的事情、也不至于太过影响工程效率，因为即使工程结构不漂亮、只要团队人员都熟悉后形成项目规范、那项目就能足够有效推进了。各种语言，项目结构多了去了，对于工程效率，通常是约定大于配置
你觉得这个好，大概率是因为你在自己的 go 项目积累初期阶段没有自己花心思去认真思考和设计工程结构，刚好又看到有可以参考的就直接拿来用、并且用习惯了，用习惯之后其实就无所谓了。所谓的实践里你们很多工程按这个目录来也清晰明了没出什么问题，但你有没有想过其实如果你早期是参考了一个其他模板，习惯后也照样清晰没什么问题？因为这中工程结构，只是目录结构而已，并不是那些决定项目生死的算法、数据结构、框架基础设施实现质量最主要因素，比如高并发高性能，一些算法、数据结构、系统编程能力直接决定了项目能否满足性能要求（尤其是对单点性能要求很高、不是无状态那种随便加硬件就能解决的类型）。所以你说这个模板你们很多项目用着没什么问题——这说法没毛病，确实没什么问题，但这并不能证明它真的就是好，并不是所有人都能够像你们一样能够轻易接受别人的某种设计审美，而且至少我接触的高阶开发人员里，不喜欢这个模板的人居多

第二，先不论这个模板好不好，作者自己冠以 standard 。项目种类很多，你要是类似 spring 或者 larval 或者什么框架之类的，自带工程结构作为自己框架的 standard 那无话可说，然而你不是框架、只是个目录结构，跟中文那些文档类的 star 项目没什么本质区别。并且冠以 go 语言本身的 standard ，作者要脸吗？说句不好听的，这叫鸠占鹊巢、沽名钓誉，个人觉得这不仅不严谨，而且不道德

第三，说说这个模板到底好不好。不同的项目类型有不同的模块、组件需要，对应不同的目录结构通常是项目自家人员设计更贴合实际审美，通常大家倒是有一个共识——对于很多不同场景时没有银弹，既然没有银弹，即使是再去研究并且列举它哪里不好都是对时间的浪费。所以这个作者搞一个自以为通用适合所有项目类型的模板（只是目录结构），我觉得说他是招摇撞骗也不为过

@joesonw 这个项目的工程结构真的没什么可参考的。

@joesonw
又是一个受害者，早期被别人带跑偏了。。。

先看下 go 作者主力和一众人怎么喷这个项目早点纠正下姿势吧:joy:：
https://github.com/golang-standards/project-layout/issues/117

虽然我仍然喜欢大道至简，但是希望有楼主这种项目能让那些对 golang 大道至简阴阳怪气的小白们闭嘴

@sunny1688
#4 简单 review 了下，先 issue 了个，欢迎多多交流

@dubdub 比如标准库 tls 或者其他一些地方，或者 fasthttp 里，用到 2^N size 对齐的多级 pool ，nbio 里用的不是固定 size 的，go 的 gc 无法确定内存的精确释放时机，如果需要比较精准控制，甚至可以 cgo 直接调用 malloc 这些，得看实际需要了。