为什么我做了 easy-model：我不想再在 React 里“到处找状态”每次做复杂页面，我都会遇到同一个问题：一个

每次做复杂页面，我都会遇到同一个问题：

一个需求改动下来，状态可能在 useState、自定义 hooks、全局 store、工具函数里各放一点。
当代码量变大之后，最难的不是“实现新功能”，而是“确认改动会影响哪里”。

我做 easy-model，就是为了解这个问题。

它的目标不是发明一套更花哨的语法，而是把业务逻辑收回到业务模型里，让 React 组件回到“渲染层”。

我想要的状态管理，应该满足什么

我自己总结了 4 点：

业务语义要集中，不要散落在 UI 层
组件之间共享状态要自然，不要手搓一堆胶水代码
异步 loading 要统一，不要每个按钮都单独维护
代码要可测试、可迁移，不和某个页面结构强绑定

easy-model 的实现方式是：TypeScript 类 + 少量 Hook + 可选 IoC。

easy-model 怎么用一句话解释

字段是状态，方法是业务动作，组件只负责调用和展示。

常用 API 就这几组：

useModel / useInstance：在组件中拿模型实例
provide：按参数缓存实例，实现“同 key 共享”
watch / useWatcher：监听模型变化路径
loader / useLoader：统一异步 loading

一个很小但很真实的例子

import { useModel } from "easy-model";

class CounterModel {
  count = 0;
  increment() {
    this.count += 1;
  }
}

export default function Counter() {
  const counter = useModel(CounterModel, []);
  return <button onClick={() => counter.increment()}>{counter.count}</button>;
}

看起来很简单，但真正有价值的是：
当这个页面从计数器成长为“筛选 + 列表 + 异步加载 + 权限判断”时，结构不会塌。

我不想把它包装成“银弹”

如果你只是做局部 UI 状态，比如弹窗开关、Tab 切换，useState 完全够用。
easy-model 主要解决的是“业务复杂度明显高于 UI 复杂度”的项目。

换句话说，它服务的是可维护性，不是为了替换所有状态写法。

你可以怎么试

我建议不要全量迁移，先挑一个模块：

登录态
用户信息
一个列表页的筛选与分页

先把这个模块的状态和行为收回模型层，再看团队协作和迭代效率有没有变好。

仓库地址：
GitHub: github.com/ZYF93/easy-…
npm: www.npmjs.com/package/@e7…

如果你也在被“状态分散 + 逻辑膨胀”困扰，欢迎把你的场景贴在评论区，我可以按你的页面结构给一个可落地的拆分建议。