codehz

多买几个机器不就好了，小主机也不占地啊，可以用 kvm 切换或者直接远程控制

ai 的迁移能力超乎你的想象（）
只要别太离谱，基本上你想到的小众语言 ai 都可以很快胜任
而且移植库也更方便了，以前还要纯苦力移植，现在 ai 翻译移植库非常容易（）

其实主要问题是
https://laike9m.com/blog/avoid-mini-frameworks,171/
引入了太多不属于库的新概念，虽然你可以解释说是大家最后都会这么做，然而最后会这么做和一开始就要这样做还是不一样的（）

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

https://grok.com/share/c2hhcmQtMi1jb3B5_424db85c-b856-4a85-a83e-d185fca2c8b7

zustand 的核心就是那个 selector 机制，避免了 context 的牵一发动全身问题
其他的一切都只是为了一个简单好用的 api ，包括那个 set get 的设计，做成这样是为了能方便被中间件扩展，某种意义上说，相比于函数式或者面向对象，zustand 的 middleware 设计更偏向于 aop 也就是面向切面编程

主要是就算你想在外面直接调用 set 也可以使用那个 selector 函数的 setState 方法，所以我完全不知道为啥你有导出 set 的想法（）

@jaydenWang zustand 的派生不是直接在 selector 里写的吗，我倒好奇你是怎么用的
语法上确实没阻止你直接导出 set 但一般人也不会这么写啊

zustand 里唯一看上去是函数式相关的，大概只有不可变数据和纯函数更新这两点了，但完全不能和真正意义上的函数式打等号，一些资料里这样写单纯是因为他们没搞清楚概念，真正重要的是那个 flux 模型，它看似与函数式紧密联系，但实际上是完全不同层次的抽象，只能说有一定的相似性

Flux 的核心原则包括：
单向数据流：数据流动是单向的，避免双向绑定带来的复杂性和不可预测性。典型流程是：View 触发 Action → Dispatcher 分发 → Store 更新状态 → View 重新渲染。
单一真相来源：应用状态集中在 Store 中，而不是散布在各个组件。
动作驱动更新：状态变化通过明确的 Action 来驱动，便于追踪和调试。

zustand 只是在这个基础上把开发体验做了一定的提升，简化了使用：
不需要 Dispatcher 或严格的 Action/Reducer 分离。
直接在 store 中定义状态和更新函数（这些函数类似于 Action Creators ），通过 set 函数不可变地更新状态。

至于为啥不用 class ，还不是因为 js 本身局限性，无法高效跟踪深度嵌套类型的变动，只能采取创建新对象的方式来触发更新——例如 zustand 同一家出的那个 valtio ，就是使用 proxy 做的状态跟踪，为了解决 js 的局限性，其实不仅带来了很多损耗，也需要遵循很多规则（ this 使用规则，还有 proxyMap proxySet 等原生对象包装）写才不会出事

我翻遍了资料也没看 zustand 说它是函数式啊？能不能先别立一个稻草人呢