挑几个来说

## 语言设计相关

> 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 性能这种压测数据不符合实际场景的情况。
所以我通常不建议直接以压测仓库作者提供的压测数据作为参考依据，包括我自己写的压测代码。所以我建议有兴趣的兄弟姐妹还是自己跑下实际代码试试看，并且也可以根据实际测试参数、尽量把各个框架的参数、配置对齐来公平对比而不是被作者自己号称的性能忽悠。

越是挣扎，越是真的要没落了。

怎么着，这年头伸手党都这么犀利了吗？又不是什么复杂的难题，要是说“请教下怎么实现”那都绝对不算是伸手党。可这连标题都是下需求，OP 头像脸都不要了也就算了，咋请教个问题也脸都不要了呢。。

是因为经济不景气、所以楼上各位就这么卷着来伺候伸手党吗？建议不要吧

早上起床气还没有散，加上是 go 的，希望 gopher 至少能动动脑子，所以对不住了各位，请收了神通吧！

塔尖以下共同富裕
中产失业拿出积蓄
人口太少鼓励生育
回到原形家徒四壁

你们这些年轻人啊，这样下去是要亡国灭种的！这样的态度要不得！
再这样下去，就只能修改计划生育政策内容了，把以前的的”旧计划”改成“新计划”：
以前不让多生，以后强制多生！以前给你们发免费的套套和避孕药以及上其他配套手段，以后免费发维生素片、壮阳催情药！妇联的大姐和阿姨们每天下班去你家里催你们圆房！按照年龄段、身体素质综合情况为每家指定频率，排好家访的 schedule ，每天去今日需要交任务的家庭、隔着门听你们完成今天的业务后在小本本上记录下来才肯离开！

@jimages
以前对陈皓不熟悉，他去世了才去看了他的主页，看到那几个抵制资本家之类的观点，觉得他人很好。但偶尔看到他的一些技术观点，我不认同。

比如只喜欢 go 的小伙子不该被技术限制这个故事：
1. 很多老手都有同样的观点，技术只是工具。但一个年轻人在技术积累期间，深挖一个方向是很有必要的，钻研一下精深一些，积累到实例之后再去扩展技能点，能让自己做到博而精，而且多数人经历几年钻研后也基本都会自己体会到技术只是工具，根本不需要年长者们提前来指导。这种指导，更多概率是造成这些年轻人博而不精，都成了 CURD 工具人。所以其实是两个不同阶段的人，年长者的建议初衷是好的、效果可能是差的。我身边就有这种例子，大专肄业的小伙子，刚工作技术很菜，拿着不够生活费的低工资只为求学习转行的机会，然后坚持了几年硬啃 c++、数据库相关的领域，现在是他们公司开发里的大拿，代码能力超过很多他的名校专业硕士同事。他几年前也是在各种技术群里问各种问题，很多老手给他说技术只是工具，幸亏他自己有坚持，没有盲从那些建议。就像罗永浩说的，不是每只鸟来到世上都是为了躲枪子的。
2. 虽然语言只是工具。但不同语言解决问题的能力，确实大不相同。最简单的方法，整体思维，如果学什么语言不重要，那也就意味着随便哪个语言都可以解决所有问题了，然而并不是，所以才会有 go 、rust 的再次横空出世并且大火。

直接看标准库源码，或者找个代码比较好的 repo ，结合 repo 看标准库源码，比看书强多了

提示：
国产鳗鱼：国内生产的添加剂导致问题的带包装鳗鱼
日本鳗鱼：从中国进口的无包装鳗鱼

2022 Go 生态圈 rpc 框架 Benchmark
https://colobu.com/2022/07/31/2022-rpc-frameworks-benchmarks/

https://github.com/lesismal/arpc

看样子好多人的迷惑都是类似的：
https://www.reddit.com/r/golang/comments/13wfae2/gowebsocketbenchmark_including_nbio/