@klakekent 因为许多人没有这样的业务场景需求

https://github.com/valyala/fasthttp

fasthttp might not be for you!

fasthttp was designed for some high performance edge cases. Unless your server/client needs to handle thousands of small to medium requests per second and needs a consistent low millisecond response time fasthttp might not be for you. For most cases net/http is much better as it's easier to use and can handle more cases. For most cases you won't even notice the performance difference.

@bronyakaka 为什么一个 http 框架需要频繁发版呢？你用经常发版的框架说明 bug 多，难道你业务没问题但是 http 框架修复问题了你节假日还要跟着更新一下发新版本？

gin 最熟悉，go-zero 用过里面的难用

https://gist.github.com/ericavonb/3c79e5035567c8ef3267
https://www.conventionalcommits.org/en/v1.0.0/#specification
网上有很多，组里遵循不遵循与我无关，我都按照一定的风格写。

https://twitter.com/CMGS1988/status/1675059389236142081
https://medium.com/@ilskdw/q-a-f6b68d074ef6
是这条推特里面提到的深圳部门的人带的团队吗？

@Celebi 这个现在性价比应该不是很妙呀

Hi，看 Shopee 的机会可以 At 我，可以帮忙介绍下不同部门，选一个符合你要求的，对深圳这边的部门职位比较熟悉 :)

觉得算法的思路上有在日常工作中帮到过我，包括更优雅的递归和遍历、了解到了一点语法糖、熟练不依赖各种包来完成一些东西，这是其一

其二就是写代码是一线工程师最直接的能力体现，代码都写不好，人家为什么要相信你能在工作中如何如何好呢，能不能写出来是一方面，思路、设计、代码结构也是一方面，有的公司也并不是没写出来直接挂的，遇到过好几个面试官都有尝试引导甚至做不出来换一题给机会的。

所以建议大家跳槽的时候还是多多准备下算法题，不会花很多时间，多看看题解和别人写的代码，对自己没坏处

@whywhywhy 是的呀不加班呀..

友情 ding 一下同事~

曾经有段实践尝试过推行第三点的写作，但是个人认为对于不太愿意（也可能只是工作比较忙，没有合适的时间）总结和沉淀的同学来说，确实是比较累人（ KPI 化）的，产出结果也不太理想。所以希望大家多多提点建议或者方案，如果好落地推行的话~回头再来 V2 反馈给大家

其实让数据库执行你的查询，同一条 sql 在数据分布不同的情况下执行路径也会大有不同，问题太过 general 了，问人还不如相信数据库的分析

@myd 那提供的条件太有限了，无法知道具体的查询 pattern，范围，这些建议都给不了

方案没有，但是提个小建议，第二点问题可能是错的

“加 2 个普通索引 online_time 和 offline_time，只能用一个，也有可能都用不上”

这个方案最理想的情况是两个索引都使用上，最终取交集，具体情况要看 DBMS 的统计数据认为交集的方案开销是否比其他查询路径小。

另一个小建议是如果你这个表很大，还有其他字段，那么加这两个索引：
- online_time - user_id
- offline_time - user_id

将取交集的操作继续缩小为不需要回表的方案，性能可能有大幅提升（安利测试看看）