伸手党真是烦

[lesismal]

https://github.com/lesismal/nbio/issues/152

连个 star 都不给，文档、例子也不认真去看就来无脑问各种基础问题，即使这样也都很认真回答他了，甚至一步到位把优化的代码写给他了，然后还是会继续问弱智问题，稍微提醒几句，既不承认又不改、再多说几句就恶语相向

伸手党见得多了，所以已经有了一定免疫力，但伸手党还理直气壮的毕竟少数，还是觉得被恶心了

看了下这个人的 profile ，应该是给别的不少仓库提过 issue ，估计有使用、至少是学习吧，包括 ClickHouse ，但是一共就给过别人 4 个 star （不包括 ClickHouse ），其他的没再多看

这么心安理得理所当然的人，真不知道是什么心态，可能他前世拯救过世界修了太多福分所以大家都欠他的吧

今天真是个 2B 日子，平常心，不能让它影响明天情人节的心绪

[zooeymango]

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

[lookStupiToForce]

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

[fenglangjuxu]

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

[chengkai1853]

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

[XiLingHost]

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

[lesismal]

@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 各种也都搞起来，看不过来就也不能那么认真回复了。。

[Jekins]

嘿嘿我知道楼主是翻译回他的还是楼主会英文...好奇哈哈

[liaohongxing]

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

[lesismal]

@liaohongxing

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

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

[liaohongxing]

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

[encounter2017]

@Herong 2048  是什么鬼 2077 ？

[lesismal]

@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 那几个月有点伤元气了，需要缓缓。。

[Herong]

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

[neoblackcap]

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

[neoblackcap]

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