去年年初，我想把家庭资金攒到 200W ；然后孩子出生，换车，公司资金链出问题，人到中年上有老下有小。导致经济严重受影响，别说上升了，目前保证很缓慢的下降没有严重缩水已经很不容易了（现如今房贷全靠媳妇撑，感谢我媳妇）

@guangzhouwuyanzu 字节的 hertz 没有字节的场景，用不到 netpoll 等特性就相当于用 gin 了，hertz 的源码实现参考了 gin,echo 等框架的特点，在阅读源码的时候基本路由方面绝大多数参考了 gin ，少部分代码风格参考了 echo 。

@CloveAndCurrant 哈哈，行吧，那我像小丑吧，大中午的～～ 该休息休息～～

@CloveAndCurrant 是这样哈，技术选型呢，可以是 LD 或者更高级的人来定，贴合自己业务场景的特点，潜在的瓶颈，规划技术架构以及技术选型来解决业务问题。团队的其他人呢，也就跟着用；所以不需要参与选型，也自然不需要了解为什么。

楼上就有人也用到 fasthttp ，他很清楚自己业务中遇到了什么问题，要怎么解决带来什么性能提升与价值。

所以，不知道不丢人，可以继续用，对不；
又不是来吵架来的，伤肝～～～

@CloveAndCurrant

一个技术贴下面， [事实] 也没有， [观点] 也没有，blabla 一堆，跟🤡一样呢。

@CloveAndCurrant 你的数据于我又什么意义？ fasthttp 的应用场景以及性能提升官网写的都很清楚； so ，你到底知不知道你们的场景为什么如此选型以及带来的性能优势如何哟；不知道就算了，不至于纠缠与嘲讽，伤肝哈。

@bronyakaka 看清了，降低并发性这部分：

我认为"在 IO 密集型业务中，哪怕存在 G 阻塞，M 挂起的行为时，Goroutine 的性能也是优秀的比线程并发强，所以它与自己比较，会降低并发行，但是这点对于其他线程并发场景，并不重要，本身就很高。" 也就不算缺点。

@CloveAndCurrant 哈哈哈哈，笑死了。 看来你是不懂的。

@CloveAndCurrant

技术选型以及性能对于基础服务的提升优势数据都没有，丢一个业务场景，可笑的家伙。

@bronyakaka
1 、goroutine 初始栈 2KB （会动态增长的，并不是说一定省内存了），而操作系统线程的栈通常 1MB
线程大小通常可以设置，但是也远比 2KB 要大;

缺点也有：
1 、没法控制怎么分配到 cpu 核上，开几个协程可能都挂一个线程上，，利用不了多核资源
GMP 模型的 M 就是利用了 Cpu 的资源，至于什么时候系统会额外的创造 M ，可以进一步了解 GMP 原理；你这第一个缺点不成立

3 、协程一旦执行阻塞系统调用，会把整个线程阻塞，导致该线程无法执行其他 goroutines ，降低并发效率
两个问题：
「 1 」，请问哪一个语言 （串行之行时，一旦阻塞了当前线程，当前线程后续还能之行动作）
「 2 」，当某个 G 被挂起，它仅会阻塞当前 G ，P 且会脱离 M ，自行寻找其他 M ，如果 M 此时不足且需要创建的话，会临时创建“M”，这恰好是优点

4 、协程不适合 CPU 密集型任务，因为没什么 io ，上下文切换反而增加了开销，，调度器也有损耗，不如用多线程直接绑定到核心上

你可以反问他一句：用户态和内核态的区别，话题终结。

@CloveAndCurrant 请介绍一下你们用 net/http 与 fasthttp 带来的性能提升指标，技术选型原因，优势在哪里，而不是你用来干嘛～～

@CloveAndCurrant 你什么场景能用到 fasthttp 的性能部分，说不出来可以开除的哦。

切换到 vscode 不用每年都去买或者折腾 license 了。

最后落地一坨不能用的 KPI 产物，浪费了人力物力财力精力现金流

@FunkYou2022 [前端，年前鹅厂毕业，] 哈哈哈哈，看错了， [前端，年前] ，看差了

前年鹅厂毕业，这两年有在做什么吗？没有一直待业吧？

这 4 个外包的面试官或许也不会得到什么正确的判断，4 个人面试一个就离谱

男模