大部分企业的业务都不需要 model 层

@Chrisssss 同意

const deps = getDeps.call(store, store); 这样的实现必须手动在 getter 写一次，@memo 指定依赖列表，完全依赖约定，把 react 的糟粕带了过来。 useStoreSelector 是通过猜测用户访问了什么属性调用 trackGetterAccess 增加引用计数，有多脆弱我就不说了，至少 StrictMode 会错误计数。此外没处理好竟态条件。 另外 View 层反向控制 Model 的缓存过于反模式，只要没有 React 组件在查看属性，就会直接删掉缓存。 Immer 混搭 weakMap 过于奇葩。 一堆 any ，看一半就没耐心看下去了。

6202 年还在依赖实验性装饰器这点就已经输了（） zustand 里想用 class 其实可以直接做一个中间件来做，以下是 ai 一秒生成的代码，可能有误，但大体思路明确 https://grok.com/share/c2hhcmQtMi1jb3B5_424db85c-b856-4a85-a83e-d185fca2c8b7

@jaydenWang #10 你没认真看吧，zustand 有阿，而且你这个比 zustand 更复杂，居然引入装饰器模式

@Ketteiron 1. 没想过自动计算依赖 2. useStoreSelector 计数不会出错，缓存不是目的，缓存是为了稳定的引用，是服务于 view 层。view 层用了缓存，不用了不缓存，不存在 view 层控制 model 层缓存，这个缓存就是服务于 view 层的 3. 调用层有完整的 TS 类型推到，实现层还有一些 any 会修复

@Ketteiron trackGetterAcces 这种设计可能是有问题的，我想想有没有优雅的姿势自动清除缓存

@codehz 第一版就是基于 zustand 封装的，但是 zustand 不是核心。核心是 immer ，不可变状态，后续就移除了 zustand

“像 Zustand 一样简单”---那我为什么不直接用 Zustand ？ 通篇看下来，你这个并没有说非常大的亮点，反而更加复杂，上手难度更加高，而且还用装饰器这种模式，你所描述的东西它都有，你没有的它也有。 还有一点，大家广为人知的 Zustand ，生态、社区，乃至各种坑都已经踩过了，ai 也已经收录了各种文档，为什么要用你这个呢？我在项目用 Zustand 也只是简单的管理一个普通的对象 store 也足以 zustand/middleware/immer 也非常优秀的实践

不是很懂，等一千 star 了再来看看