我当初就图便宜买了些国内云的节点，一些节点上什么服务都没部署，然后收到了被攻击的报警、建议购买它们的高防服务。
所以别以为是被“别人”刷了，刷你的人很可能就是服务于你的人。

> 前端 10k star 不算 s 好，但也 z 很不算多。后端 star 可比这难获得得多了。

-> 前端 10k star 不算少，但也不算很多。后端 star 可比这难获得得多了。

前端 10k star 不算 s 好，但也 z 很不算多。后端 star 可比这难获得得多了。

不要一竿子打死所有国内搞开源的啊，我们后端或者其他非前端领域很多人没拿开源搞收费挣钱这种啊

学了那么多年复杂的 CS 理论，反倒是连基本逻辑都越来越乱了，而且越来越像孔乙己。
真是，哎，可惜，可惜了

@Slurp

> 写个 C++ 写个 Rust 不会，复杂点的概念理解不能，学了个 Go 所谓「大道至简」天天的在这里怼天怼地怼空气。

看样子你不只是没教养，连逻辑都混乱。我都好奇了，我十几年前就在写 c/c++，因为它俩开发效率低产出慢，等你写完功能上线了市场都被别人占领完了才来搞 go ，怎么就不会 c++了。你这个逻辑推理能力是真的好强啊！

> 😁 喷个 b 人都能说我没教养，那后面还有更难听的呢。

你随口说别人是 b 人，并且表情还这么欢乐戏谑，那正好证明我说你没教养的逻辑是正确的呀。后面还有什么你尽管讲出来好了，我也乐于见识一下你素质到底有多低

> FrankHB 这种起码有点乐子

幻 他活在自己的语言律师的乐子里，这是他的自由。但是我可从没见他像你这样随口管别人叫 b 人。先抛开技术不谈，单就幻的素质教养就比你高出很多的。至于技术，他是偏学院也好理论也好，你是什么派别也好，我这种是实践派，技术不只是你对哪些语言语法达到多高的理解就有多高的社会贡献或者价值，你要是真造了什么牛逼语言造福一个领域和一大片程序员那也是你的丰功伟绩，但如果不是，可能还不如实践派的大伙对社会贡献来得实在。

而且既然看你口气也都是老年人了，那我也用因为觉得后辈不可期对未来失望而跟你在这生气了，最多你就是个顽古不化自以为是能玩弄一点编程语言艺术的小丑罢了，因为毕竟我没听说过哪位讲中文的大佬对某个编程语言领域做出了什么超凡脱俗的巨大贡献或者开拓。

所以也别扯犊子那些虚头八脑的，比如你可能喜欢像跟幻讨论问题的那些话题，我是实践派，要真论什么语言语法，那你牛逼我不懂那么多，我说的那些个也不是语言本身的，懒得跟你浪费口舌😁

> 反反复复 if err 是哪个语言。

天下也不是只有异常系统或者 rust 的那个什么来着或者其他一些这几种姿势是唯 N 审美，你不喜欢 if err ，喜欢的人多了去了，我只见 go 越来越多人喜欢，越来越多业务交给 go 做。
最简单的一点，那么多大厂搞它替换其他很多语言，合着你天下第一、别人那些大厂的技术大佬都不如你呗？那请你继续活在你自己的世界里自娱自乐吧，这样挺好的

偶尔出来像这样咬一口别人也没关系，我不介意


> 😁 你要喷设计模式，那我请你在 Go 里不用 Visitor 模式实现一下解析 AST 。
> 😁 你要喷 FP ，那我请你了解一下 Algebraic Effects 。
> 😁 你要喷 TCP ，那你先解决一下中国运营商阻塞 UDP 的问题。

这逻辑就更混乱了呀，如果一个东西是垃圾，还要让我去花更多时间去深入学习理解它，这不更是在浪费我的时间吗？
你门口遇到一坨狗屎，单观其形状颜色甚至临近被它气味熏到时就知道它是不好的了，难道你还真要上去吃几口深入研究下为什么它不好？

我这个人非常工程实践实用主义，我只原意把时间花在那些有利于工程实践的事情上。
所以拜托你不要以为自己读了点什么垃圾，就一定要别人也要学会这些垃圾然后再跟你讨论问题，太狭隘，太逻辑混乱！
简直莫名其妙，十分搞笑！

送你个词，沉没成本效应：沉没成本效应(Sunk Cost Effects)是指为了避免损失带来的负面情绪而沉溺于过去的付出中，选择了非理性的行为方式。
因为听你的口气，自是学了不少 CS 的知识，因为投入的太多舍不得放弃，所以在那自嗨得不行。

有这个能读明白那些垃圾知识（虽然垃圾，但毕竟也挺复杂）的智力水平，至少也是上过不错的学校，自己读瞎了却不自知，可惜了你还有和你类似的一种人了。

😁 😁 😁

@Slurp

这是我两个库：
https://github.com/lesismal/nbio
nbio 这个，截至目前 go 社区 poller 框架唯一支持 tls/http1.x/websocket ，poller 框架里性能也基本是不比其他任何一个低

https://github.com/lesismal/arpc
arpc 这个是我的 go rpc 框架，功能不只是 rpc 、支持的业务类型比 rpc 广泛得多，至于性能，你可以去看三方评测：
https://colobu.com/2022/07/31/2022-rpc-frameworks-benchmarks

我好奇你这种还有给你点赞的小子们都是什么技术水平和技术审美，你们回复这些内容时候自己把问题想明白了吗，你们觉得我这种是属于 b 人 的时候，你们自己对我说的那些垃圾理解到位了吗？

本来说了不再回复这个帖子了，一上来就看到个 b 人，真是后辈可期！

> 看到 Go 社区都是这种 b 人我就放心了

@Slurp 小子嘴巴放干净点。即使是讨论技术，你可以用观点来反驳，张嘴管别人叫 b 人 是从小家里大人不管教学校也不教吗？

另外，你技术是有多屌？你敢保证你自己喜欢的那些东西就是好的美丽的？
我上面提到的一众都是垃圾的东西，我都能喷出个所以然、为什么这些东西垃圾，只是喷了很多次懒得每次再打字说一遍罢了。

既然我不喜欢的那些东西看样子你都挺喜欢，那目测你只是个搬砖的罢了。

技术或者技术审美差也就算了，还没教养，而且还有好几个点赞的，真是一丘貉。

@Nazz 之前的帖子喷了不少，浪费时间，这个帖子我不继续回复了
https://www.v2ex.com/t/816040#reply90
https://www.v2ex.com/t/816040?p=2#L151

@Nazz
TCP 握手和断开、HTTP1.0 和 2.0 、Restful 、Actor 、函数式编程、设计模式。。。
这一大堆玩意的主要内容没一个好东西，都是垃圾

链式不直观清晰，不容易理解，链式本身就很丑。

总结：OP 什么破品味！少制造这种辣鸡封装！

挑几个来说

## 语言设计相关

> 3. defer 的概念非常有趣，也很符合 Go 的设计主旨，不知道 Go 语言中是否有类似 Python 中上下文管理器的工具（即实现打开文件时确保其使用后被关闭，上锁时确保使用后会开锁等操作）

既然知道 defer ，defer close/unlock 就可以了，不应该还有这种疑问。不同语言提供不同的东西，也没必要非得别人有啥就要 go 有同样的东西。
另外，比如 os.File 这种，即使不 defer close ，gc 时也会自动 close 、不至于泄露，只是可能不太及时，或者如果你的代码泄露了没有 defer 也没有 gc 才会副作用:
https://github.com/golang/go/blob/master/src/os/file_unix.go#L239

> 4. 从原理角度，如何理解 channel 的调用开销。使用 channel 传递数据究竟是一种廉价操作，还是昂贵操作，其究竟是否依赖锁？按我的理解它依赖于事件循环，每次激活后才会唤醒依赖它的协程，应该是无锁的，但是书里写它其实是有锁的，我不是很懂。

直接看源码吧，也可以配合一些别人的文章来看源码，比这种问答要认识的更清晰：
https://github.com/golang/go/blob/master/src/runtime/chan.go#L160
https://github.com/golang/go/blob/master/src/runtime/chan.go#L457

5. 如果 channel 有锁，通道通信相较于内存共享的优越性体现在哪里？

channel 适合业务层简单逻辑：你把它当成进程内的消息队列就可以了，与锁的区别主要是带容量、可以把逻辑串行化并去锁，用于异步、解耦之类的比较好。但简单的队列数据结构同步，channel 性能是不如锁的、而且用锁可以在当前上下文继续进行剩下的穿行逻辑，放到 channel 后则需要其他地方去异步从护理了，未必就是 channel 方便。
性能需要的场景，比如基础设施领域，锁仍然是主力，不能被 channel 替代。

> 6. 对于 string 的处理方式。我们都知道 string 通常是比看上去更复杂的数据结构，教学视频中看到的所有赋值和参数调用基本都是直接传值，实际情况是否如此，这是否意味着如果不加优化通常效率会很低？

你说的 string 传值只是 string 结构体定义的这个小结构体：
https://github.com/golang/go/blob/master/src/runtime/string.go#L232

并不是需要深拷贝 string 的 payload 然后再传值，所以相比于传指针开销并不算大

## 多线程调度相关

> 2. Go 的调度模型下，单个协程应该是很省的，但是如果我有一万个协程同时对一个 map 进行交互，此种情况下应该如何进行优化？（或者说 Go 应对此种场景时也并无特殊优势?）

1) 减小锁粒度：无非就是多加点 shard/bucket ，减小每个 map 元素数量，从而减小锁粒度
2) 提高并发度：1 ）中处理后，就可以去多协程去搞每个 shard/bucket 的 foreach 了，典型的如广播场景，广播优化主要就几个点：避免写阻塞，降低锁粒度，提高并发度，批次发送

## 最佳实践相关

> 1. 通常情况下，Go 语言调查未知对象内部属性和方法的最佳实践是什么？

设计者应该根据需要设计数据结构，除了三方互接并且对方乱搞，为什么一定要依赖调查？绝大多数正常的业务领域，脑子拧巴的实现者才喜欢去猜、让自己或者让别人用奇淫巧计去实现需求
避免使用反射。

那些不理解甚至嘲讽 go 的大道至简的人，其实就是花了很多时间学会了很多其他语言的奇淫巧计，沉没成本效应，让这部分人舍不得放弃以前学的那些糟粕思维，然后惯性地用那些思维来思考 go ，然后才会有这些垃圾问题和需求。当然，我不否认少数时候 go 里也需要奇淫巧计，我自己也用。


其他问题好像多数偏于垃圾问题，不答了

认真学习下 新时代中国特色社会主义思想 ，被精神病后给医生背诵。

@huanglm
> 窃以为“不谙世事，不懂事故”不适用于此场景，此场景更贴近于“恶毒”，显然是在自身利益受损后才被“不懂世故”。若以理工“直”的特征来推断 当在刚得知楼主行为不妥后 立即上报。

我也不知道有什么词更准确，因为不知道 OP 的说法是否完全属实、有无偏私。

单讲私活，如果是实情，接私活这种事情也可大可小：
1. 往小了如果跟公司利益无关只是影响工作产出之类的，那就是生活不易挣点外快值得理解可惜被发现了
2. 往大了说如果公司利益相关那可能甚至违法犯罪了
但不管哪种，OP 都不占理，被发现了被开并不冤枉。

还有，看 OP 的描述，首先是“老板直接安排她的工作，因为不符合技术开发的要求，说了一句，她当场心态崩溃”，单凭 OP 的描述，我字面理解应该是这个女生提了一些需求，被 OP 以技术原因拒绝了。
因为并不知道具体的需求和技术原因，所以咱们外人无法判断这个女生的需求是否合理、OP 拒绝需求是否合理。

所以如果尽量保持客观，就不应该因为 OP 先发贴、冠以小人的帽子这些一面之词而简单给女生扣上恶毒的帽子，具体情况如何，还是以事实为依据比较好。

当然，如果 OP 私活并不影响公司利益并且事实就是她恶毒，那我只能建议大伙接私活还是要处理好与工作的关系，并且也一起给她中指。

> 加不加数学系不影响阅读啊

@huanglm 会有影响，理工"直男直女"多，不谙世事，不懂世故，做出这种事情来就比较符合"逻辑"

go 和 rust 是龙兄虎弟左邻右李伯牙子期，不要把他俩对立，而是双剑合璧干死其他静态类型语言：
1. 用 go 处理性能不是最敏感但是性能和开发效率都很重要的很多偏应用业务比如 CURD 、以及少量系统编程业务比如云原生
2. 用 rust 去搞安全要求高的性能要求强的去干掉 c/cpp 为主，干掉其他为辅

应该一起喜欢这两个

@doanything 赶巧了，我也是前几天看到别人收藏里有这个，就也收藏上了😄

这里找找看：github.com/iGaoWei/BigDataView

> nbio VS gnet

@qbmiller

对于七层协议：gnet 不支持 TLS/HTTP/Websocket ，gnet examples 对这些 7 层协议相关的示例似乎并不是完整功能，离实用还差很多，gnet 的 README 里所说的 HTTP 性能并不是真正的完整功能 HTTP 框架，当初那个只是简单地解析 HTTP 换行符之类的这种，所以用于跟别人完整功能的 HTTP 框架对比性能本身就是不合理的。有给 gnet 作者聊过这个问题，他解释了原因：
https://github.com/panjf2000/gnet/issues/182
好像有其他人在 gnet 之上封装过 TLS ，但易用性相比于 nbio 应该还差很多吧，结合实际场景的应用不知道效果如何。

对于四层：我也有做测试： https://github.com/lesismal/go-net-benchmark/issues/1
nbio 的 used by 列表里有 gnet-io/gnet-benchmarks 但现在的 gnet-io/gnet-benchmarks 好像是没有包含 nbio ，可能是测过之后删掉了吧：
https://github.com/lesismal/nbio/network/dependents?dependents_after=MjQ3MjQyNjExMzI

根据我自己压测的情况是，单就四层而言，nbio 和 gnet 性能差不多，跑多轮测试有时候 nbio 高一点有时候 gnet 高一点，我的环境里跑 10 轮，可能 nbio 有 7 、8 次会略高一些。

因为遇到过多次如下情况：benchmark 库官方提供的压测数据与我自己实际跑他们官方测试代码的数据差异较大，也包括一些类似 gnet HTTP 性能这种压测数据不符合实际场景的情况。
所以我通常不建议直接以压测仓库作者提供的压测数据作为参考依据，包括我自己写的压测代码。所以我建议有兴趣的兄弟姐妹还是自己跑下实际代码试试看，并且也可以根据实际测试参数、尽量把各个框架的参数、配置对齐来公平对比而不是被作者自己号称的性能忽悠。