Ketteiron

坏过两次，离谱

packageManger 是 node 的实验性功能，没事最好别用。
我猜你们有个依赖只能在 pnpm9.4.0 下正常安装，甚至我大概已经猜出来包名了，它才是大雷。

@Ketteiron 如果性能开销不重要就用它+对应插件。Kysely 稍微折腾下也很好。我目前在用 PostgreSQL+RLS+Drizzle ，但我不会推荐别人用 Drizzle 处理多租户。
如果只想简单地获得一套开箱即用的多租户，就用 superbase 之类的。

多租户跟框架没多大关系，跟 orm 或者数据库有关系。
在 nodejs 这块，首推 Prisma ，其次 Kysely ，其他的就不推荐了，Drizzle 不支持在应用层进行隔离，只能用 RLS ，如果你的数据库用 PostgreSQL 可以考虑。
Prisma 性能奇差无比，

代码即文档没什么毛病
文档这玩意不就是 xxx 模块有什么 xxx 功能，需要实现 xxx 接口等等，让 AI 扫一遍就行了
现在这年头确实没必要写那堆冗余的文档了，有什么注意的请直接写到代码注释里，真有人写也是 AI 生成的大概率没精修过的废话文档

什么都上 AI 模型只会让各种工具越来越慢。
就算是最小的模型，你能接受它的体积吗，你能接受以后你的电脑上安装几百个软件附带几百个大模型吗。
按主楼用例来看，你需要的是类似智能调整词库权重的东西，当连续/高频命中关键词时调高对应词库权重，正常输入法都会有这种机制，但自带输入法不会考虑这种场景，所以你要做的是换一个输入法，而不是屁大点事都上大模型，它不是万能许愿机。

杀猪盘是真的，灰产是真的，注意分辩。

因为很难对单体服务划分职责，你可能没在大公司干过，无法理解跨部门、跨公司在超大型项目协作上会遇到什么难题。
代码没写几行，整天就在分锅扯头皮了，比菜市场还乱。
微服务可以明确划分物理与逻辑边界，减少人员摩擦与管理成本。

不过微服务被大量滥用就是另一回事了。
一切都是有代价的，微服务的几百字营销用语懒得复述，缺点是性能差、请求时间长，光是链路追踪、海量日志处理、分布式事务就带来无穷隐患，中小厂基本只能买现成服务。
如果把`微服务`当做一件商品，那许多事情就会有合理的解释。一件商品自然会有适合的用户，但为了赚取更多利润，销售们会把它强硬推销给不适合的用户，包装上好看的外观，精心润笔，夸张地讲述好处，对坏处闭口不谈，与卖保险的没有区别。
拿你经常推销的 thinystruct 举例，你认为它适合所有用户吗，假如推广这个框架有利可图，你会做相同的选择吗？

你儿子大概离"开 ssh ，让我上去看看"也不远了