Ketteiron

@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' } }
在这之前不装插件我不知道怎么才能显示完整类型，试了下一些插件效果不好