每次看到这帖子都以为是那个 CF

20 若不润，30 徒伤悲

整体而言，南方优于北方，除非家庭背景在北方。

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

@liaohongxing

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

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

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

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

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

@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 之类，应该是有三个月以上了，没细算过

@tywtyw2002
@ericwoflskin

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

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

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


@paulw54jrn 感谢支持！

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

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

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