那就别跳，本就没太多进去精神（不是丧气话），折腾出去如果变动还没有 N 了，这点涨幅不一定能抗风险；原公司不卷能苟住还能摸鱼，就待着吧。幸福指数高一点；这么多年没什么进步跳槽也不会带来进步的。要想公司的现金流和未来抗风险性。

如果新环境做的内容是你喜欢的，那另行讨论，如果只是尚可的新晋涨幅，不足以抗财源风险。

OP 个人或者所在公司部门，有什么业务优先接入 MCP 做业务测试吗？或者玩具测试。

[这题用了十年了，面下来能写清楚这题的大概只有一半不到？]
说明题不好

除了遍历 或 递归遍历 + 反射判断类型，比较 value 后替换罢了，没其他好办法。

想到了前几天一个「格式化时间输出的面试题」给的一个答案：
if value == 100 {
value = 200 哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
}

典型的场景：客户端 复杂无规则 payload JSON 请求体 + 客户端 payload 签名；服务器针对 payload 验签比较。

hhkb 用了快 10 年

@mumbler 你要不要试试楼主的需求看看你的结果如何？

去年年初，我想把家庭资金攒到 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 带来的性能提升指标，技术选型原因，优势在哪里，而不是你用来干嘛～～