楼上两位已经把别人要回答的都回答过了。

tmux
vim
go(相比 c)
五笔
google or bing
stackfull
github
飞书文档

撸代码很快乐啊。面试面不上也很好玩，发现自己以前没有重视的技术点。后面打算多花时间玩下云原生的技术。

这飞书用得很 6 。可以分享下用法吗？

@dongtingyue 之前用的是第三方库吧。

//放结果伪代码
// 每个 go 程的 id 已经固定下来，就是 for 循环启动的 index.大家操作自己的私有 index 。为啥会有竞争？
for i :=0;i < M;i++ {
i:=i
go func(){
slice[i] = result
}
}

难道 slice+context.Context+errgroup 的组合不行？

1.分配 M 容量的 slice 。放 M 个 go 程正常运行的结果。每个 go 程都有自己的 index，所以存结果这块都不要加锁，相当舒服的操作。

2.context 当作异常终端点。每个 go 程都持有这个 context 变量。任意一个 go 程错误,cancel 。任意 go 程检查 ctx.Done()。所谓 “如果其中有一个任务返回 error 时立即结束” 完美实现。

3.检查 errgroup 的返回，err != nil，就返回错误，else 部分没有错误，返回第 1 步声明的 slice

@Claar 如果题主给数据，就 nice 了，哈哈。

@Claar ok，没问题。

@Claar 我用两种方式实现过 trie tree 。前者是标准的，后者是分裂式。benchmark 数据后者会快点。这样吧。感兴趣你可以提供 test data，我有时间写个代码 benchmark 看下。

@Claar 把共同前缀字符串提取成一个 node 速度应该会快，就是管理 node 的分裂比较麻烦(一开始是一个 root 节点，有冲突就分裂新的 trie 节点)。就跟 httprouter 的实现一样。

@eudore 2.Parse 长，没办法，如果 go 里面有宏替换，或者手动内联优化，也不需要写这么长了。这么写只是为了减少进 stack 出 stack 的成本。

1.哪怕使用内存分配比官方库快也是很容易的。分配可以保存 http header 内存＋浅引用指向 field 和 value+惰性解析。

@lesismal good 。这样有一些好的讨论别人也可以看到。

@lesismal end 打印的是空行，修改下 fmt.Printf 就可以看到。是否复制我的 example 代码，

MessageComplete: func() {
// 消息解析结束
fmt.Printf("\n")
},

@lesismal 我觉得你和我讨论技术是挺好的，这块可以放到 github issue 上面。

@lesismal 你的用法，和我的设计还不一样，我一开始的方案，是一个 Request 包解析完成之后，手动调用下 Reset()。所以不调用 Reset()。第二个 Request 包是不解析的，这时候对于解析器是 MessageDone 的状态。这块可以再优化下使用体验。

从打印你也可以看到，哪怕是粘包，第一个 Request 也是完整的拿出来了。

@lesismal 。。。？ httparser 也返回了各 header 字段。以及 body or chunked body 。
我不知道你开火的焦点是？如果是数据没有返回，答:都返回了。

@lesismal 设计的时候支持分段传入，内部是一个状态机。

@shyling 标准库的 http.ReadRequest，每秒只能处理 124MB 。相比之下 httparser 可以 300MB，性能还是可以的。