一、状态管理概述：什么是状态、状态管理的核心问题、为什么需要分层架构
好，咱们直接进入正题。
状态管理，这个词你肯定听过无数遍了。但说实话，很多人做了几年开发，对「状态」的理解还是模模糊糊的。我刚开始带团队那会儿，也踩过不少坑。今天咱们就把这事儿彻底聊透。
1.1 什么是状态？
状态，说白了就是「数据在某个时刻的快照」。
你想想看，一个用户登录了，他的用户名、权限、购物车内容——这些就是状态。页面加载中、加载完成、加载失败——这也是状态。甚至你鼠标悬停在一个按钮上，那个「悬停中」的布尔值，也是状态。
我个人习惯把状态分成三类：
- 本地状态：只属于某个组件，比如一个输入框的当前值
- 共享状态：多个组件需要访问，比如当前登录用户信息
- 服务端状态：从后端获取的数据，比如商品列表
核心要点：状态就是「会变化的数据」。不变的东西不叫状态，叫常量。
我在项目中遇到过最典型的反例：有人把整个API返回的JSON直接塞进全局状态里。结果呢？一个页面改了数据，另一个页面莫名其妙跟着变了。调试了整整两天，最后发现是引用没断开。嗯，这种坑，踩过一次就记住了。
1.2 状态管理的核心问题
好，知道了什么是状态，那状态管理到底在管什么？
其实就三个核心问题：
- 数据从哪里来？—— 数据源的问题
- 数据怎么变？—— 变更流程的问题
- 变了之后通知谁？—— 传播机制的问题
你想想看，一个简单的计数器，点击按钮加1。数据源是组件内部的count变量，变更流程是点击事件触发setCount，通知谁？就通知这个组件自己重新渲染。简单吧？
但一旦系统复杂起来，问题就来了：
- 两个组件需要共享同一个数据，谁负责更新？
- 数据更新后，十几个组件都要重新渲染，会不会卡？
- 异步请求的数据，加载中、成功、失败三种状态怎么管理？
我曾经踩过的坑：一个电商项目，购物车状态散落在五个组件里。结果用户加购后，结算页显示的金额和购物车页不一致。查了三天，发现是某个组件用了旧的缓存数据。从那以后，我定了个规矩：共享状态必须集中管理，绝不允许「各管各的」。
所以，状态管理的本质，就是解决「数据一致性」和「变更可追踪」这两个问题。
1.3 为什么需要分层架构？
好，现在聊到重点了。
你可能会问：我直接用全局变量不就行了？为什么非要搞分层？
我直接说结论：不分层，项目活不过半年。
为什么？我给你讲个真实经历。
几年前我带一个中大型项目，初期图省事，所有状态都放在一个全局Store里。UI组件直接读写Store，业务逻辑也写在组件里。前两个月开发速度飞快，大家都觉得「真香」。
到了第三个月，噩梦开始了：
- 改一个UI样式，不小心把业务逻辑改坏了
- 想复用某个逻辑，发现它和组件绑死了
- 测试？根本没法测，因为逻辑和UI搅在一起
说白了，这就是典型的「面条式架构」。所有东西混在一起，牵一发而动全身。
分层架构要解决的就是这个问题。它的核心思想很简单：把不同职责的代码分开，让每一层只关心自己的事。
我一般把状态管理分成三层：
| 层级 | 职责 | 典型内容 |
|---|---|---|
| UI层 | 只负责展示和交互 | 组件、样式、事件绑定 |
| 业务逻辑层 | 处理数据变更规则 | 状态更新、异步请求、校验 |
| 数据层 | 管理数据源和持久化 | API调用、缓存、本地存储 |
一个小技巧：判断分层是否合理，就看「如果我把UI从React换成Vue，业务逻辑层能不能不动？」如果能，说明分层到位了。
分层架构的好处，我总结了几点：
- 可维护性：改UI不会影响业务逻辑，改逻辑不会影响数据源
- 可测试性：每一层都可以单独写单元测试
- 可复用性：同样的业务逻辑，可以给不同UI框架用
- 可扩展性：加新功能时，只需要在对应层加代码
当然，分层也有代价。代码量会多一些，初期开发速度会慢一点。但你要想清楚：你是想快三个月然后痛苦三年，还是慢三个月然后舒服三年？
我个人选择后者。而且说实话，一旦你习惯了分层架构，再回去写「面条代码」，你会浑身难受。
总结一下：
- 状态是会变化的数据，分本地、共享、服务端三类
- 状态管理的核心是数据一致性和变更可追踪
- 分层架构把UI、业务逻辑、数据层分开，让代码更干净、更可维护
好，这一章就到这里。下一章咱们聊聊具体怎么分层，我会拿一个真实项目来拆解。到时候你就知道，分层不是理论，是真能救命的。