@flynaj #18 raid 不保证正确性，保证的是可用性。op 遇到的静默错误，什么 raid 都没用，甚至可能发生错误数据把正确数据给覆盖了。要稳定的话，需要 ecc 内存和 zfs/btrfs 。

@kuanat #9 DDR5 的内置 ECC 是水货，检测不了 CPU<->内存的传输错误，并且单比特错误会自我纠正不会上报。
要遇到静默错误很容易，咸鱼买一块垃圾内存就行了
https://quantum5.ca/2024/12/22/on-btrfs-and-memory-corruption/
因为绝大多数内存都能正常工作，所以遇到文件莫名损坏的概率确实极低，一辈子碰不到一次完全正常。而碰上了也很正常，毕竟"可靠"的软件运行在并不可靠的物理世界上。

@DICK23 #1 Prisma 没这问题，因为它的类型是自动生成的，不像 drizzle 需要 schema->type 产生实时大量 tsserver 性能开销。但 Prisma6 的类型系统有重大缺陷，用过 drizzle 的用户可能无法习惯。drizzle 的设计目标之一就是解决 prisma 大量令人难以忍受 DX 问题。
Prisma7 用了 ArkType 可能性能会稍好一点。
另外据说 drizzle 测试版的 ts 性能提高了二十倍，我还没时间去验证。

另外 schema->type 是唯一正确的路，即使它再慢也要忍下去。

因为阿里、京东有信心把钱赚回来，羊毛出在羊身上。你先搞清楚商业行为和国家政策的区别再说。

@sillydaddy #35 U 盘/SSD 如果不经常通电可靠性远不如小容量机械硬盘。
核心数据我建议至少两个网盘，必要的话多加一至两个 OSS 。
M-DISC 盘虽然便宜，但是读写设备贵，高档的要上千块，而跨越长时间的写和读，通常是两个不同设备，设备本身也会老化，新的不一定会兼容旧的。
如果是连接 PC 的硬盘，检测坏道加个开机脚本，或者每隔几个月用 CrystalDiskInfo 看一下硬盘健康度，不通电的没办法，祈祷它别坏。
PAR2 是对一个压缩包做冗余，如果将来重新读取这个压缩包，损坏数据小于冗余体积就能恢复，一般需要专业软件，例如 MultiPar 。

再说宽泛点，半个 typescript 的开发都被 vercel 绑架了，除非不用 turborepo 之类的工具
vercel 的成功之道就在于锁定用户，作为他们的用户，零配置零折腾就能成功运行，随之而来的代价就是便利性锁定

五十年比较难。
损坏文件主要有这些因素：磁盘老化、坏道、比特翻转+纠错/校验失败。
如果是真的非常重要的数据，仅仅保证不丢失是不够的，像图片编码损坏几个 byte 会表现出几个像素有问题，但它的原始版本已经永久性消失了。如果是一些特定编码，例如压缩包损坏一个字节就打不开了，而视频根据损坏的区域不同(索引、关键帧、普通帧)会有不同的后果，但都是不可逆的损失。
这些问题催生了 ZFS ，ZFS 假设硬盘完全不可靠，随时随地会发生各种静默错误损坏文件。
如果你想要长时间、极度可靠地保存重要文件，需要 3-2-1 备份，尽量使用 ZFS+ECC ，还有 BTRFS 这个选项。

但是正常人要实施且长时间维护这样系统说实话过于困难，不管是金钱还是时间。
PAR2 可以看做是 ZFS 懒人版，也算是个能用的方案。

我现在已经放弃折腾 ZFS 了，所有文件都放在 PC 上的 4 块 2T 固态里，维护一个哈希列表，配合一些冗余校验方案，脚本定时同步到各大网盘，定时扫描/检查是否发生文件损坏。即使哪天固态寄了也就换一块的事。

冷存储是一个极度理想化的方案，假定数据保存数十年不会发生变更，但事实上把时间跨度拉长到几十年，发生数据损坏几乎是必然现象，而真正能保证可靠持久化的存储技术普通人花不起这钱。
相对来说热存储是储存数据的最佳方案，最简单就是定时把数据同步到两个以上网盘。现代人类脱离了网络就无法生存，其实数据也一样，只有热的、活着的数据才能不断校验它是否发生了变更，而放进冷藏室的数据你只能祈祷数年、数十年后取出来与原本完全一致，但这是不可能的。

数据的可靠性不取决于工具、方式，而是取决于投入的时间。

@yuhuai66666 #5 家里 chrome 周末闪退，进去后链接全灰，历史记录同步几乎失效，今天来公司打开电脑发现也跟着灰，那就是云端数据是有问题的。
这应该是 chrome 或者 google 的问题，我现在另一台电脑全访问了一遍一个个点亮，历史记录在这台电脑上是好的，晚上看看需不需要重装。
我猜是某个 bug 把有问题的数据同步到云端去了，如果有另一个能登录的 chrome 设备应该能"修复"。

我也碰到了同样的问题，试了各种方法确实都无法恢复，打算重装了

你得用 context7 ，AI 会自己查最新版文档

@UnluckyNinja 官方文档这么写问题很大，似乎是暗示 return 一个 reactive 会丢失响应式，我第一次看文档时也是这么认为的。实际并不会，因为返回的是代理对象，只有对代理对象进行解构才会丢失响应式。
我想没人会 return obj ，正常都是 return { obj }
ref x,y 和 reactive ({x,y}) 是等价的两种写法，只是后者不能解构
const {obj:{x,y}} = useXxx()
我想也没人这么闲用嵌套解构语法
文档只需说不建议返回 reactive 对象就行了，初学者可能会以为 {reactive()} 也是不行的。

对 token 消耗确实很不友好
经典的 oop 就是这样的，浪费至少一半代码用于封装面向过程的核心函数。
创建一个对象、互相依赖，仅仅是为了执行必要的几个函数，而 AI 不得不先理解对象是如何抽象的，顺着依赖拓扑结构深入检查接口的实现是什么，有什么变量，有什么内部逻辑，等梳理清楚了 token 都快干没了。

@skkakaka2 #13 并不行
```typescript
interface A {
b: B
}
interface B {
c: 'c'
}
const a: A = { b: { c: 'c' } }

console.log(a)
// ^?
此时 a 的类型是 A ，而不是 { b: { c: 'c' } }
在这之前不装插件我不知道怎么才能显示完整类型，试了下一些插件效果不好

简单变量肯定全是 ref ，我先假设你指的是对象用 reactive 还是 ref 包裹。
如果你写了很多 usehooks ，或许会发现 reactive 比 ref 更好用。
例如简化业务逻辑经常会自行封装 useTable/useForm 等参数，然后传递 api 类型，用泛型推断出参数和返回值类型。
此时可以用这样的写法
const params = reactive({}) as T
const model = reactive({}) as K
暂时用空对象欺骗下 ts 推断正确类型
而不是得到 T | null ，不得不写没必要的可选链，只要源头的类型是正确的，那么运行时实际也是安全的。

@iseki #10 Date/Time/DateTime 都有。
只是性能不太行，功能也少。

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

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