@tiRolin 什么原因，没信心找到下一份工作？
公司又不是你开的，裁员了除了走人还有什么办法，不然世界上就不存在裁员了。
假如招一个人进来无法简单开除，那么面试难度增加一百倍你能接受吗。

@muchan92 #68 缺点是几乎无法正常测试，所有规则都是黑盒，就如#62 说的，可维护性是非常重要的，能保证大型项目能正常迭代。
你这种做法相当于是放弃了各种测试和静态分析，在组合数量爆炸时虽然不用梳理大量组合逻辑，但是一个规则对其他规则以及集合总体的影响是几乎无法预知的，有好处，也有坏处，在我看来坏处大于好处。

好奇看了下 demo 给我看晕了。
这要是真有人用在生产上，怕是一半时间都在 debug 。
声明式/响应式编程我承认有一定合理性和可行性，本质上是希望将 n²的组合复杂度缩小为 2n ，虽然其实并没有消除任何复杂度。

@bruce0 因为你的学历没达到他们设定的基本线，所以 hr 的消息列表看不到你，现在几乎都是用第一学历筛掉大部分人，候选人实在太多了

@COOOOOOde 我建议五年后再来问

```typescript
function isEmpty(a: unknown) {
if (a === null || a === undefined) {
return true
} else if (typeof a === 'string') {
return a === ''
// 如果空字符串不认为是空值
// return false
// 或者这样
// return a.trim().length === 0
} else if (Array.isArray(a)) {
return a.length === 0
} else if (typeof a === 'number') {
return false
// NaN 实际上不是空数值，不应该这样使用下面的判断
// return Number.isNaN(a)
} else if (a instanceof Map || a instanceof Set) {
return a.size === 0
} else if (typeof a === 'object') {
const proto: unknown = Object.getPrototypeOf(a)
if (proto === Object.prototype || proto === null) {
return Reflect.ownKeys(a).length === 0
}
}
return false
}
```
发现自从我写 ts 之后，再也没写过这种类似的辅助函数了，没时间跟隐藏的运行时异常打架
https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABFApgZygRgBQEMBciA5EYgD7G6kUBGccANirkhQAzmKYCUiA3gFgAUIkQxgiPL0EjRiCAjSMUAOgZwA5lOFzEAej26jiAHoB+HYgC+iFAzQp+l0QrBKmazdtmiDx3eaWVsJWQA

@mqnu00 js doc 只能定义静态的简单类型，它没法判断一个变量经过某个逻辑判断后变成了什么模样。
例如一个参数可以同时是值、数组或函数，这很常见，ts 中如果你用 if(typeof 判断出是什么具体类型，数组分支里点号按一下数组的可用函数列表就出来了，函数分支里才能()，逻辑越复杂代码越长，ts 对可读性的帮助越大。
ts 开启 checkJs 后会尽力检查 js 文件每一行代码在上下文里是否正确的，不过帮助有限，如果写上 js doc 就可以更精确地检查类型，再加上 typescript-eslint ，像某个角落漏了 await 也能查出来。

我的建议是别用 js 了，换 ts ，0 false undefined null '' [] {} 没有任何歧义
甚至就算写 js 也可以用 ts 规则检查，人脑的静态检查永远比不过语言类型

@crossoverJie 还是远不如 kt ，kt 至少能少写一半废话

@GreatAuk #1 这个 pr 不会合并的，四年前就提出来了
类似的解决方案一堆，都是暴露出内部函数，但是无法 merge 就无法保证迭代
https://github.com/vuejs/core/issues/6038
https://github.com/vuejs/core/pull/4339

坏过两次，离谱

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

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