伸手党真是烦

这次这个我看他 star 的仓库里有个是中文的，估计是国人吧

之前还在一个 slack go 频道看到有个人提问某个 websocket 库的一个用法，说肯付费$50 ，倒不是为了钱，因为没用过那个 websocket 库所以好奇看了眼随便就回答他了，也没跟他要钱，然后提问的那个人直接把他发的内容删掉了...
当时就感触，歪果仁也有不少逗逼啊

你不爽了其实直接随便回答点模糊的东西搪塞他就行了...

如果从自己身上找问题的话,你会发现,你其实完全可以拒绝回答,当作没看见.

这种人真是的，别理他就完了。
“爷忙得很，哪有空搭理你” Go f**k yourself.

不一定要回复啊。那些大的项目，哪个不是几百上千个 issue 的。

伸手党见过太多了，开源只会吸引白嫖王者，皆是白嫖之王，开源作者只能用爱发电，何必为一些没有价值的人贡献呢

遇到弱智问题，只要网上能搜得到的，就不要回了，直接丢个付费技术支持的方案。

"you can't throw a bunch of code and expect people to read and figure it out. I have a lot of code to read and write already and I expect certain libraries to do certain things."

有被笑到

点了个踩

感觉之前跟在 B 站上有个 2 货评论人家一个教学视频一样，原话如下："这个视频太垃圾了，讲的一点也不好，别人千万别看，要把自己的时间用在有用的事情上"，然而大多数人都觉得这个视频很好，讲的很透彻，井底之蛙用它自己狭隘的观点去看待知识世界，自己看不明白以为别人也看不明白，这种自以为是的心态注定这种人都没办法成为一个厉害的人，下次看见这种人就别理他就得了，想问想用，付费解答，他们这种人纯属浪费时间

提示“发布这个内容需要你已经注册满 1000 天”，不知道是不是因为 at 各位进行回复导致的，或者内容太长了？

一开始提问也还好，但是怕遇到这种豪不思考并且还得寸进尺的，我中间已经比较委婉说了让他自己搜一些基础知识否则我英语回答不到位，结果人家直接给我"no worry..."告诉我不用为自己英语担心、让我放心回答，然后继续弱智问题，所以我才会直说让他自己认真读代码和思考一下，然后人家就干翻我了 :joy:

@PerFectTime
我也是被这句噎笑了，就差我跪着把代码提交到它项目了　

奇怪，at 多几位就提示需要注册满 1000 天，以前好像不这样子

你把他气跑了，他去 eranyanay/1m-go-websockets 每个被 merge 的 pr 下面问去了，因为那个仓库把 issues 功能关了

https://github.com/eranyanay/1m-go-websockets/pulls?q=is%3Apr+is%3Amerged

你要知道在中国遇到 垃圾人的概率是很高的

其实 GitHub 有个 block user 的功能，被 block 之后他就再也不能在你的 repo 里发 issue/comment/pr 了，遇到这种人直接 block 了之

@mdgwmt0 也不一定是中国人，从页面和历史完全看不出来是中国人。楼主说 star 有个中文仓库就是“中国人”这种逻辑有问题。那个仓库也有英文分支的“English version repo and Gitbook is on english branch. Just enjoy：)”。

直接关掉，使用类的问题是 question 又不是 issue

同类问题回答一遍就好了.. 一般问题直接搜 issue 查找有没有历史 QA . 新问题就回答一次

想到之前的一个经历，steam 写了个游戏指南，有人来问一个细节，说卡关一个月了，就给他耐心解释很多遍。
完了，他就说十分感谢您，希望能送一个游戏，价值多少的都可以，您可以看我的游戏库，我不缺钱。我说不需要，平时都玩主机。
然后又要我开放愿望单，说在里面给您挑一个，我仍然说不需要。
于是他就问我电脑的配置，我随便说了个显卡，然后这个人就说，很抱歉本来想送 2048 给您的，但是您的显卡显然不满足要求。
当时我就气笑了，2048 刚发售热度很大，但我并不感兴趣也没有要你来送，一开始您您的以为礼貌原来阴阳怪气。
再上 steam 一个月后了，指南有新消息提醒就进去看下，发现这个人改了昵称删了好友，能看到改昵称了是因为指南下有他的历史评论。

@0o0O0o0O0o
eranyanay/1m-go-websockets 这个库，去年有人在我 arpc 的仓库里提到过，建议我参考它一下，所以我去简单扫了几眼他的源码，目测是有问题的并且写了个 demo 很容易就复现了，在这里和后面的部分： https://github.com/lesismal/arpc/issues/2#issuecomment-746694287

他们只依赖 easygo 实现了事件触发读，却没有实现异步流解析、半包处理、并且对于单个 conn 仍然是阻塞读完整包，所以当一个 conn 收到 half-packet 的时候，这个 conn 的 Read 就阻塞了，而这个 conn 阻塞，它所在的 goroutine （可能是 poller 协程或者数量有限的协程池）就阻塞了，进而让其他 conn 等待。我之前在这个仓库里提了这个 issue 但是才发现作者竟然把 issue 给禁了？所以看不到了。我也到他们最终使用的 gobwas/ws 里提了 issue 和复现代码，并且有其他人也给他提过 issue 因为遇到过我说的问题，gobwas/ws 的作者更逗，不想解决问题，反而直接 close issue 。

eranyanay/1m-gowebsockets 、gobwas/ws 这些，都不应该被部署到生产环境，否则慢连接攻击下，甚至不需要攻击，公网有时候就是不够稳定的，他们服务就延迟感人了。所以其实这些库也解决不了那孩子的问题，其他一些异步网络库 evio gev gnet 都还没有支持 tls 、http ，只有 gev 支持了简单的 websocket 但也不支持 tls http 。

go 框架里能搞定 1000k 的，暂时全网就我这一份了。。。:joy:

@mdgwmt0 看运气吧，正常人还是多数

@wzxlovesy 他这样做之前，不知道他是这种。他这样子之后，他自己都说了不再来了，哈哈哈，所以算了，万一哪天他成长了呢

@skiy 对，所以我也只是“估计”，老外不是也遇到过逗逼，这玩意跟地域、种族发达程度受教育程度有关系，可能比例有高有低，但是对于个体事件、没有直接关系，看运气，碰到了是自己倒霉:joy:

正常，现在包括除非我一眼就能看出问题在哪的，不然都当作没看到了。你只要一回答他就觉得你帮他解决问题是应该的。

不必和垃圾一般见识。

之前有一个清华研究生找我，期望我协助他调试计算工作站。理由是，他没搞定，看到我的视频，晓得我会。

我说可以帮忙。但是在搞定之后，请写一份简单的帖文，记录一下如何搞定这种计算场景的服务器配置，以便其他同行参考。

我耗费了四十分钟，帮清华的博士研究生搞定了机器调试。未收到一句谢谢。后来提醒对方，写个记录，供大家参考，然后被拉黑了。

其实，没啥技术含量，看英文 manual 搞一通就行的。

简单的英文手册都看不懂，也没心思看。
捣鼓一周没搞定。
经他人协助搞定，也不曾道谢，也无任何分享精神。道德品行恶劣，估计博士要延期是大概率事件。

所谓高学历人才都是如此，其他情形，垃圾就更多了。

以上仅仅基于我自己的个人经历。不代表其他情形。

可以不回

@abbottcn
“然后被拉黑了”这操作有点太过了，防着别人图他啥似的

@ohmyself 以后再遇到这种，我就尽量不回

直接拉黑就好
https://twitter.com/kant777
可能是同一人

@mirone 没事，平常心，"不愠不郁"是下一个修炼目标:joy:

楼主，你理他干嘛。林子大了，什么鸟没有。

一般来说，如果不骚扰你的话没必要去 block 。

再说了开源精神，并不是提倡给用的人当老师，什么问题都去解答。MIT license 本来就是 ABSOLUTELY NO WARRANTY ，没有任何去跟他人说明的义务。

远离人渣，你对他的任何善意帮助其实都相当于变相助长他的人渣行为。
所以好人尽量帮，人渣就不给他们渣的机会。

repo 不错， 先 star 一下

你这个项目写了多久啊

@tywtyw2002
@ericwoflskin

恩恩，以后遇到不合理的问题就不回了，既浪费感情又浪费自己时间。

以前看到一些关注度高的项目作者不回复或者很久回复，因为作者们确实事情多、issue 也多，忙不过来。

但是自己项目关注度不高，闲余时间就尽量回复了，而且多回复一些，以后有其他人遇到类似问题直接搜出来就不用重复回复了。只是没想到这次遇到的这位会这样子 :joy:


@paulw54jrn 感谢支持！

只能说程序员的世界太单纯了，像我弟做淘宝的，那真是什么人渣都有，你还不能对骂，否则淘宝分分钟下架你。

@proxytoworld
分两个大阶段

第一阶段是只支持 poller ，实际上不复杂，具体花费的时间不记得了，核心部分主要是 io 、其实只要几天，剩下的就是换不同的姿势折腾和测试，比如 timer 是用时间轮还是最小堆，内存简单优化、接口易用性扩展性之类的偶尔完善下，实际花费的时间不算太多

第二阶段是对 tls/http1.x/websocket 的异步支持，也支持 client-side ，支持同一个 engine 里跑 client/server/tls/non-tls 。这个去年也消耗了几轮，实现 http1.x/websocket 的异步流解析器，tls 太复杂、图省事直接魔改标准库实现了异步解析器支持。另外花费的最大头时间是内存池优化，把 4-7 层，从 tcp 到 tls 到 http/websocket 各层的内存池打通。因为全是异步（可能 half-packet ），涉及很多 half-packet buffer cache ，打通这几层细节比较多，测试也麻烦，花费的时间比较多。也没有用其他那些基于同步方案的 2^N size 内存池，因为同步方案，每个 conn 一个协程处理读，循环读，buffer size 可控并且容易复用，不涉及复杂的异步 half-packet cache 逻辑，所需的 buffer size 也容易设定，2^N 逻辑也比较容易，而异步方案里，不确定性很多，比如对象、buffer 的跨协程生命周期管理，half-packet 相关的涉及很多 mem move/copy ，用 2^N size 实测反倒比标准库方案内存占用更多、十分拉垮。所以这些细节花费的时间较多，到主体成型，加起来花了估计有三个月以上吧，加上各种 example 之类，应该是有三个月以上了，没细算过

@tyrantlucifer 这种还有点善意提醒的已经是无知但中立的了，在 B 站看过很多优秀的教学类视频里有人因为看不懂直接骂老师傻逼的。。
有时候想写点分享之类的，一想到要被迫跟这种人打交道，直接就打消念头了

可以不予回答，或者简单回答一句：『我这会儿比较忙，你自己在琢磨琢磨』。
如果对方停止了，那算事情搞定。
如果对方不依不饶，那么直接不予理会。

没必要再垃圾人身上消耗任何精力

@lesismal
"这次这个我看他 star 的仓库里有个是中文的，估计是国人吧

之前还在一个 slack go 频道看到有个人提问某个 websocket 库的一个用法，说肯付费$50 ，倒不是为了钱，因为没用过那个 websocket 库所以好奇看了眼随便就回答他了，也没跟他要钱，然后提问的那个人直接把他发的内容删掉了...
当时就感触，歪果仁也有不少逗逼啊"

大概是 2015 年，openstack 相关问题，网上不少论坛有发，我因白嫖学校实验室和机房，可以摸索不少问题，并且不断复现记录问题细节，结果网上有人问了问题，拿到解决办法，直接删帖，当时我就心里裂开了，我分享出去是为了更多人看到，没想到有人那样做。再往后，我就长心眼了，别人问问题，我先截图存档，长图也存档，然后带着问题单独在其他地方也发一遍，避免被这种删问题的人坑了。

@YaakovZiv 还遇到过更奇葩的，去某个中小公司面试，面试官比较稚嫩，问一堆他们项目里遇到的实际问题，我就把解决方案都给面试官教会了，然后面试结束给个很低的薪资问我来不来，只能一笑而过，且当手有余香吧

从整个人类社会的视角来看，具备正常的表达，沟通，理解能力，属于稀缺技能。

所以呢，有时候官腔是必要的，就是那种说了等于没说的那种答复，其实就是表达了我和你之间有距离，而且我也不想拉近这个距离。明白人就明白，不明白的下次不予理会。

遇到垃圾问题三步走
延迟回复->延迟回复废话->close

这种一看就没意义的 issues 转到关联问题，然后关闭。

有一说一他的英文比很多中国人好
但是也有很多看起来是高级机翻的东西
我不太好判断是个哪里人
但是肯定是垃圾人

借个楼，我突然无法发布新主题了，怎么回事

issues 对于大多数人来说，就是客服中的工单系统，使用问题，需求，全部都往这扔。

@abbottcn 哈，你怎么知道他是 thu 的？还有，到底是清华的博士还是研究生？

确实如楼主说说的那样，伸手者、白飘者实在太多太多了。自己动脑子、动手没有一分钟的时间，反而看个某音、某信有大把的时间。

@pi1ot 那么整天侃大山、无所事事、摸鱼、得过且过的表达、沟通，理解能力，属于充足技能了？

这个贴真是宝藏啊 国内的 golang“生态“吗

楼主淡定，遇到会喷的伸手党更酸爽。

@mdgwmt0 #16 这个不是中国人

最近 python 想换 go ，http client 全网查了五天，想找个简单的牛逼的，都是一点点的看文档，现在一看到 socket 马上反应就是 go 。。。泪。楼主的好东西，star 了

lz 回答他问题的耐心也是绝了

直接 close 。

伸手就算了，主要是有些无耻之徒还连基本的礼貌都没有，严重让人反感

已 star

现在我也可以理解之前那位删库的 faker.js 的作者的心情了

突然有点明白那句：大佬都是有脾气的。。
因为没脾气的要么被磨得有脾气了，要么被磨得厌世了

@abbottcn 拉黑不能忍啊

垃圾人不用浪费表情，直接关 issue

"you can't throw a bunch of code and expect people to read and figure it out. "

卧槽,有内味了.冲鼻!

1. 写好文档
2. 回复"RTFM"
3. close issue

把仓库设成捐助可见即可

多谢楼主，已经 block 他了

楼主居然能这么仔细的回复真是好脾气啊 要我就甩链接关问题了

上头, 味太冲了. 作者对于技术问题的态度我是认得.毕竟翻过 nbio 相关的 issue, (就是不在自己的文档里好好写, [/玩笑])

我还记得作者在某个地方写过 "老夫不装了", 贼有意思的辩论贴.

@PerFectTime #8 哈哈哈哈哈，我也是被这个笑到了

看了一下 issue,作者挺耐心的。这种人直接 close issue 并且 block 就好了，不用理他。

幸福的烦恼，我的垃圾项目有人来烦我就好了

@twing37
#71 文档确实难写，异步库并发、时序相关的细节太多了，但是提供给应用层的接口仍然是同步方案，异步不容易描述清楚、写多了反倒会让写同步逻辑的同学迷惑，所以是写了很多 examples 为主，
#72 对，最开始发关于 nbio 的帖子的时候，记得有个 'byte0' 大神给我一顿教学，哈哈哈，我一顿回复后都没鸟我。后来在其他帖子里见到他有点黑 go ，at 他他也不鸟我，估计把我 block 了吧

作者真是位好脾气的大佬

你看，这 issue 回复里都能扯到种族问题上去了...

唉 一言难尽呀

我之前做过公司某个开放平台的技术支持（没有义务，只能说热心答疑吧），好多问题简直了，不管文档写的多简单，甚至给出了开箱即用的 demo 。遇到过最无语的是，某段 demo 因为历史原因是 jsp 写的（可以直接放 tomcat 下运行），被人说是他是写 java 的，你给个 jsp 的我怎么办

有的人真的脸皮特厚,我每次提 issue 都要再三自测按要求给复现,看到那种“我的问题不是这样的”给个报错截图跟项目毫无关系的 issue 我看一眼都感觉都浪费时间

我觉得这个不止国人有，在外企工作，国外的一个不知道啥部门的人跑来我的 wiki 文档底下提蠢问题，我回复了过后被缠上了，开始了保姆育儿式的手把手步骤教导，最后还被对方说帮助不大然后一句感谢不说直接走人，气的我差点当场脑溢血。对面还是个 senior software developer 。
从此再也不会好心贴冷屁股，要找我帮忙不给好脸色甭谈。
所以面对傻*，你得把你的高冷人设立起来

点进去看了下
原来是上次在 v 站 看到过的 上次已经 star
我 star 多半是因为觉得 技术好 准备啥时候学习下
当然我用到的话 多半也会 star

楼主贼强，太有责任心了，这么详尽的 issue 解答，看 Github 这么多年，头一次见到。再回答下去都可以去写书了

对于这种人建议你学一下 SagerNet 的作者，你看看他是怎么处理的
https://github.com/SagerNet/SagerNet/issues?q=is%3Aissue+is%3Aclosed+label%3Aspam

@cdxjcl123 其实脾气一点都不好，只是线上也拿他没办法，要是线下我就直接对他狮吼功了。。


@janxin "race issues"应该是指 golang race condition, 一些变量未加锁并发访问时，开启这个选项会有 race 相关的 warning ，就是并发访问竞争、一致性这种问题。std 方案那种无状态的服务通常很少涉及这种。一些场景能够满足并发访问安全，则也是没必要加锁的，nbio 里的应该都是 ok 的。race 只是帮助检查代码可能存在的问题，确认没有问题就好了


@iyaozhen 干净的代码，demo 比文档看着更直观。项目历史包袱确实烦躁，即使你给他 java 他也可能有另一种吐槽


@zooeymango 你这种就是社区之光了，哈哈哈，都这样子的话，估计 linus 也就不会火爆脾气了


@lookStupiToForce 对对对，巨婴！太可怕了。老外确实是大神多，但是更多人也是不钻研很深，都是专注自己业务领域、经验多了升职加薪就行，因为人家没有 35 淘汰、可以干到退休，人家的社保也时真能保障未来，所以都是命吧。。。


@fenglangjuxu 感谢兄弟支持！


@chengkai1853 过奖了，我是 issue 少所以这么耐心，中文的 issue 还好，英文的我这回复一条也花好一阵功夫，要是真多了，估计也扛不住。。。


@XiLingHost 项目情况不一样，issue 数量不多，也还好，要是哪天有机会多起来了，模板 lable 各种也都搞起来，看不过来就也不能那么认真回复了。。

@lesismal 跟 echo 这种标准库框架结合，也能有高并发吗 ，echo 是不是一个连接一个 go 协程 在加上 ws 的协程，这样子行吗

@liaohongxing

与其他标准库为基础的框架结合，是替换了标准库 net.Conn 这些，因为 nbio 是异步的了，不能再像标准库那样子一个连接一个协程了，要用 nbio/nbhtt/websocket ，代码在这里：
github.com/lesismal/nbio-examples/blob/master/http_with_other_frameworks/echo_server/echo_server.go

gin 的也在这个仓库里，其他标准库为基础的，也能类似方式

@lesismal 我翻看了一下源码，发现是接管了 echo , 把底层替换了，http 好像是自己实现的。这个 http1.x 实现的完成度怎么样，能接受 POST 的 multipart/form-data, application/x-www-form-urlencoded, application/json 吗

@Herong 2048 是什么鬼 2077 ？

@liaohongxing http1.x 应该是比较完整了，你可以试下。multipart/form-data, application/x-www-form-urlencoded, application/json 之类的，这些不影响 parser 解析规则，解析后的数据是丢给了标准库的 http.Request 里的 header ，标准库支持的应该就自动支持了，如果遇到 bug 可以开个 issue 给我

fasthttp 好像还没支持 trailer ，nbio/nbhttp 也是支持了的

websokcet 通过了全面的测试项 Autobahn Test Suite ，readme 里有链接可以参考下，这得感谢外国友人 acgreek 来提需求和 pr 。而且因为支持并发写，本身也是非阻塞写，所以不需要像 gorilla 那样在遇到广播场景时直接写就行，不需要像 melody 那样在 gorilla 基础上额外封装 chan 的 send 队列（基于标准库的 conn 是阻塞写，广播场景如果某个连接窗口拥塞、写阻塞了，广播循环时其他 conn 就都得等着了，也是线头阻塞的一种）。
BTW ，melody 的接口设计很赞，个人很喜欢。前阵子发现它有个可能宕机的 bug ，去提了 pr：
github.com/olahol/melody/pull/67
但是 melody 作者似乎不维护了，issue 列表里有其他人提问，不知道作者是不是遇到了什么困难放弃了，各位使用 melody 时注意下，可以修复下然后使用自己的 branch 保平安。衷心希望 God Bless Him!

http2.0 太差了，不打算支持了，如果哪天有体力，可能会考虑开另一个库去改造下 quic/3.0 ，因为虽然是 udp ，但目前 go 版本的 quic 实现还都是提供了同步 conn 方案、仍然是一个 session 至少一个 goroutine 的方式，并发量大应该还是 cover 不住 1000k 。去年就有想过，但是也是够复杂，而且去年撸 tls http websocket 那几个月有点伤元气了，需要缓缓。。

@encounter2017 笑死 2048 是什么鬼 我说怎么感觉怪怪的

@bequt http client 可以去 awesome-go 上面看，好一点的都是基于 Builder 模式的。性能我就不知道了。
不过一般没啥特殊要求，我一般都是使用标准库中的 net/http ，毕竟没有外部依赖。仅供参考

其实也可以说，开源是兴趣，项目就是这样。如果你想要更加进一步的服务，比如教你如何用好，甚至写代码都是可以的，只要加钱。比如 5k 写几个 use case 还是很好的。
代码是自由的，但是人工服务本来就没有提，所以适当收费也是好的。