Ketteiron

@Kirkcong #68 各大中小厂商的文档只能用狗屎来形容，如果再打开官方提供的 SDK 看一下源码更是不堪入目。

const deps = getDeps.call(store, store);
这样的实现必须手动在 getter 写一次，@memo 指定依赖列表，完全依赖约定，把 react 的糟粕带了过来。

useStoreSelector 是通过猜测用户访问了什么属性调用 trackGetterAccess 增加引用计数，有多脆弱我就不说了，至少 StrictMode 会错误计数。此外没处理好竟态条件。

另外 View 层反向控制 Model 的缓存过于反模式，只要没有 React 组件在查看属性，就会直接删掉缓存。
Immer 混搭 weakMap 过于奇葩。

一堆 any ，看一半就没耐心看下去了。

函数式的重点在于不可变更新。

> 费力地模拟着面向对象
不费劲，闭包是穷人的对象。

你说对象=状态+行为

更准确地说
对象=原型链+状态+行为
闭包=状态+行为

get() 和 this 有本质上的区别，this 只会带来 bug 和心智负担。

> 它是“二等公民” ：你必须显式地调用它 get()，而且它打破了 JS 引擎对 this 的自然优化。
这是我 2025 年听到最好笑的笑话，比这个还好笑 /t/1177228

我有个不相关的问题，这位老哥会被疯狂 @吗？
https://www.v2ex.com/member/click

不太可能是网络波动导致的，nfs 默认使用 tcp ，tcp 是解决网络不可靠的传输协议，要么完整地传输过去，要么抛出一个错误提示传输失败。
"Corrupted block detected"
"Restored data doesn't match checksum"
这已经说明了文件在存储前/后发生了变更，我是觉得你的内存或者硬盘至少坏了一个，另外系统卡死大概率是相同问题，全部排查一遍吧。

@yeqizhang #9 标准结论一直都有啊，用不用 jwt 只看需不需要 jwt 。
jwt 实际上是拿 cpu 解密开销换取数据库查询开销，为了安全性可能会双 token(15 分钟危险期) or 单 token+redis(秒级封禁)。除此之外有非常多的组合方法，但各有侧重点没有高下之分，软件开发不存在通用最优解。

大概率内存出问题了，基本上 99%的文件静默错误来源于内存比特纠正失败。
生成的压缩包带上了错误的校验和，那肯定会失败，一开始就不存在正确的数据。再一次证明了 ECC 内存的重要性。

把建模从 interface 换成 schema 不就行了，与其从类型生成 runtime ，不如限制 runtime 并派生完全相同的类型。
类型生成 runtime 是有正当用途，某些框架例如 Vue 可以通过类型生成 runtime ，但是业务也这么干我感觉是歪门邪道。
这也是一个老生常谈的话题，我觉得所有尝试反射、保留元信息的做法都是错误的。
https://github.com/akutruff/typescript-needs-types