真正做起来东西很多，比如各种 oidc 登陆以及 email 登陆，处理账号关联，修改重置密码，修改邮箱等。另外还有 web 端 cookie ，cors 处理之类的。建议完全看一遍 auth0 的文档，或者开源的 ory kratos 之类的，你就会感受到整套的 auth 系统有多复杂

先加个 AI 吧。这是收费 Team 版的功能:
- Warp AI with up to 100 requests per user per day
- Shared notebooks in Warp Drive (coming soon)
- Real-time terminal sharing (coming soon)

现在唯一实现的就是 AI ，估计这也是 Warp 能融资的主要原因。否则一个纯 terminal 感觉不太可能有人付费

后端不也卖。看看极客时间上毛剑，许式伟卖的，销量估计吊打 twitter 这些

直到生命结束有点极端了

"从已有的产品形式进行融合而诞生的新型种类。", 我觉得优化已有产品添加 AI 功能更为实际，比如 Discord 加个 AI bot 。除非是完全依赖 AI 的产品，比如 AI 出图，很多人的需求可能确实就是 AI 出图不用修改 ps 什么的，这就适合做个全新的产品

这类问题没有完美解决方法，想尽可能自动处理的话可以参考 rails 的 Russian doll caching 。另外推荐看看这篇文章 https://blog.the-pans.com/when-and-how-to-invalidate-cache/

@Nazz rwmutex 的 scale 能力一直有问题，比如最近我看到的这个 issue https://github.com/cockroachdb/cockroach/issues/109443

@infinityv 全局 rwmutex 估计只会被秒杀

@Nazz 应该是一直在优化

专用分词器是指带词库的那种？短文本 title 很适合 ngram ，长文本由于各类干扰词很多而且为了缩减总 token 量才需要词库

@NoOneNoBody 我也不是作者

结构固定直接走代码生成不就行了

@hkhk366 按照官方说明索引 100 万文件要花 1 分钟： https://www.voidtools.com/en-us/faq/#how_long_will_it_take_to_index_my_files. 考虑到要建索引和分词 1 秒 100 万不太可能。倒排索引我觉得 1gram 和 2gram 就行。文件名 1 个索引，文件大小 1 个索引。文件名索引存[]string ，其他索引直接存[]bytes 方便 bitwise 操作。比如搜"abcd", 那就 ("ab"索引 AND "bc"索引 AND "cd"索引) 。然后再 AND 文件大小索引。最后反查一遍文件名数组把 bitwise 结果为 1 的找出来。对于 regex 的情况如果包含常固定字符可以先用 ngram 过滤一遍，剩余结果再真用 regex 匹配

没明白 abc.txt 难分词的原因，搜索 a 那所有包含 a 的文件都应该显示。另外"倒排 100 万文件大约需要 1 个 GB 的空间"感觉也不对，你是用 sqlite 的全文检索测试的吗

看上去 google cloud function 可以无限扩展 https://cloud.google.com/functions/docs/configuring/max-instances?hl=zh-cn

缓存策略相关的论文很多，包括各种改进版的 lru 策略也很多

@Nazz Hierarchical Timing Wheels, 我是照着 caffeine 的 java 代码翻译的，也可以 google 。LFU 就复杂些了, 建议去看 W-TinyLFU 的论文。简单来说 frequency 数据是存在 Count-Min Sketch 这种概率类数据结构里的，所以占用空间很小

@Nazz 知识盲区，也许这个能参考一下: https://github.com/golang/go/issues/54766

我以前在的时候得物有工时排行榜的，而且还是公开的。你早下班会拉低整个组的平均工时