@shubiao #71 AIDA64 之类的一大堆啊，鲁大师是面向小白用户的，几乎没有参考价值，也就是推广做得好。

go 的时间库确实没有大而全的，一旦需要用到只能东拼西凑
如果只需要 Local ，我会用
https://github.com/googleapis/google-cloud-go/blob/main/civil/civil.go
但也就只有 Local

目前所有 AI 检测 AI 的项目都是狗屁不通的玩意，也就骗骗投资人。
如果什么提示词都不加，AI 生成确实会有十分显著的特征，例如大段废话，低质量注释。但使用提示词、agent ，它生成的文本与真实人类所写的几乎不存在统计学上的区分性。

@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 生成的大概率没精修过的废话文档