企业官网建设流程全解析

1. 从一个被低估的日常操作说起

如果你写过前端，大概率经历过这样的场景：页面上一个筛选条件改了，结果列表没刷新；或者用户点了“加入购物车”，按钮上的数字纹丝不动，非得手动刷新页面才更新。这类问题的根源，十有八九都指向同一个东西——State 操作。

State，中文一般叫“状态”，听起来像是个很学术的词，但说白了它就是“当前这一刻，你的程序记住的那些数据”。一个计数器当前是几、一个弹窗是开着还是关着、一份表单里用户填了什么、一个列表当前加载到了第几页，这些都是状态。而“State 操作”，指的就是对这些数据的读取、修改、派生、同步、持久化这一整套动作。

我做了十多年前端和全栈，踩过的坑里，跟状态相关的至少占一半。早期用 jQuery 时代，状态散落在 DOM 里，改一个地方要手动同步另外三个地方，改漏了就出 bug；后来有了各种框架，状态管理成了核心命题，但新的问题又来了——状态放哪儿、怎么改、什么时候该派生、什么时候该缓存，每一个选择都直接影响项目的可维护性。

这篇内容适合所有写界面、写交互、写数据流的人看。不管你是刚接触状态概念的新手，还是已经用过几种状态方案的老手，我都会把 State 操作这件事从底层逻辑到实操细节掰开讲清楚。核心关键词就一个：State 操作。我会围绕它讲清楚状态该怎么设计、怎么改、怎么避免那些我亲自踩过的坑。

2. State 操作的整体设计思路拆解

2.1 为什么状态管理会成为核心难题

要理解 State 操作为什么难，得先明白一个事实：状态本质上是随时间变化的数据，而人脑不擅长处理随时间变化的东西。你写代码的那一刻，脑子里想的是“现在这个值是多少”，但程序运行起来，这个值可能被五个地方修改，修改的顺序还不确定。这就是复杂度的来源。

我见过太多项目，一开始状态很简单，一个变量搞定。然后需求来了，要跨组件共享，于是提到父级；再然后兄弟组件也要用，于是搞了个全局对象；再再然后，不同页面要缓存不同状态，于是又加了一层。最后这个状态网络变成了一团乱麻，谁改了它、什么时候改的、改了之后谁受影响，没人说得清。

所以 State 操作的第一原则是：状态的归属要清晰，修改的路径要唯一。一个状态数据，应该只有一个“主人”，其他所有需要用到它的地方，都是通过某种约定好的方式去读取，而不是各自持有一份副本然后手动同步。这个原则听起来简单，但落地的时候有大量细节。

2.2 三种主流状态操作范式的取舍

从实践来看，State 操作大致分成三种范式，各有各的适用场景，我做个对比：

我个人的经验是：界面相关的状态优先用不可变替换或响应式订阅，业务数据的状态可以用可变但必须收敛修改入口。为什么？因为界面渲染的本质是“根据当前状态算出该显示什么”，如果状态可以被随意改，那渲染结果就不可预测。而不可变替换的好处是，你每次拿到的都是一个快照，比较两个快照是否相等就能判断要不要重新渲染，这个判断成本极低。

响应式订阅则是另一条路，它把“谁依赖这个状态”这件事交给系统去追踪，你改状态，系统自动找到所有依赖方去更新。好处是写起来省心，坏处是依赖关系是隐式的，出问题的时候排查链路会比较绕。我一般会在状态和界面绑定非常紧密的场景用它，比如表单联动、实时预览这类。

2.3 状态分层：把大象切成块

不管用哪种范式，状态一多就必须分层。我的分层习惯是这样的：

• 视图状态：只跟当前界面有关，比如弹窗开关、输入框聚焦、当前 tab。这类状态生命周期短，组件销毁就该没了，绝对不要往全局放。
• 会话状态：跟当前用户会话有关，比如登录信息、权限、主题偏好。这类状态跨页面存在，但用户退出就该清掉。
• 领域状态：跟业务实体有关，比如订单列表、商品详情、消息记录。这类状态需要缓存、需要同步、需要处理并发修改。
• 持久状态：需要落到本地存储或服务端的，比如草稿、设置项。这类状态要考虑序列化和版本兼容。

分层的意义在于，不同层的状态，操作策略完全不同。视图状态随便改，反正影响范围小；领域状态就要谨慎，因为可能多个地方在用；持久状态更要小心，因为涉及数据一致性。我见过有人把弹窗开关放到全局 store 里，结果两个页面同时打开弹窗互相干扰，这就是分层没做好。

3. 核心细节解析与实操要点

3.1 状态读取：什么时候该派生，什么时候该存

这是 State 操作里最容易被忽视、但影响最大的一个决策。举个例子：你有一个商品列表状态，还有一个“选中商品数量”要显示。这个数量，你是单独存一个状态，还是每次从列表里算出来？

我的答案是：能派生就不要存。为什么？因为一旦你存了，就有两个数据源，它们可能不一致。列表删了一个商品，你忘了更新数量，界面就错了。而派生的话，数量永远等于列表里选中项的长度，不可能不一致。

但派生也有代价，就是每次读取都要计算。如果计算很便宜（比如求个长度），那无所谓；如果计算很贵（比如遍历几千条数据做聚合），那就要考虑缓存。缓存的策略是：用派生值 + 记忆化，也就是只有当依赖的源状态变了，才重新计算。这样既保证了一致性，又避免了重复计算。

判断标准很简单：这个值能不能从其他状态唯一确定？能，就派生；不能，才存。比如“用户输入的搜索词”不能从别的地方推出来，必须存；“搜索结果的条数”能从结果推出来，就派生。

3.2 状态修改：收敛入口与不可变更新

状态修改最大的坑是“到处都能改”。我接手过一个项目，同一个用户信息对象，在七个文件里被直接改过属性，出了 bug 根本不知道是谁改的。后来我们做了一次重构，把所有修改收敛到一组 action 里，每个 action 有明确的名字和参数，改完之后问题排查效率提升了一大截。

收敛入口的具体做法：

1. 状态本身不直接暴露可写引用，只暴露只读视图
2. 所有修改通过一组命名清晰的函数进行，函数内部负责生成新状态
3. 每个修改函数只做一件事，不要一个函数改五个字段

不可变更新是另一个要点。很多人觉得不可变就是“每次复制整个对象”，其实不是。对于嵌套结构，你只需要复制变化路径上的节点，其他节点可以复用引用。比如一个三层嵌套的对象，你只改了第三层的某个字段，那只需要新建第三层对象、新建第二层对象、新建第一层对象，其他兄弟节点引用不变。这样既保证了不可变，又不会带来太大的内存开销。

// 不可变更新的典型写法 const newState = { ...oldState, user: { ...oldState.user, profile: { ...oldState.user.profile, nickname: 'newName' } } };

这段代码看起来啰嗦，但它的好处是：oldState完全没变，你可以随时拿它做对比、做回滚、做时间旅行。而且因为兄弟节点引用复用，比较新旧状态时，只需要比较变化路径，性能很好。

3.3 状态同步：跨组件、跨页面、跨端

状态同步是复杂度飙升的地方。同一个状态，可能在多个组件里显示，可能在多个页面间传递，甚至可能在多个端之间同步。同步的核心问题是：谁先改，谁后改，冲突了听谁的。

我的经验是，同步要分两种：单向同步和双向同步。单向同步简单，一个源，多个消费方，源变了通知消费方就行。双向同步麻烦，多个源都能改，就要处理冲突。

对于单向同步，用发布订阅或者响应式系统就够了。对于双向同步，我一般会引入一个“单一事实源”，所有修改都先提交到这个源，由它来决定最终值，然后再广播出去。这样冲突就在源这一层解决了，消费方不用管。

跨页面同步还有个特殊问题：页面可能被销毁重建。这时候状态要么提升到页面之上，要么持久化到本地存储。我倾向于前者，因为持久化涉及序列化和反序列化，还有版本兼容问题，能不用就不用。

3.4 状态持久化：序列化的坑

持久化看起来简单，存进去读出来就行，但坑很多。第一个坑是循环引用，状态里如果有互相引用的对象，序列化会直接报错。第二个坑是不可序列化的值，比如函数、日期对象、Map、Set，直接序列化会丢失信息。第三个坑是版本兼容，你今天存的结构，明天代码改了，读出来就对不上了。

我的做法是：持久化之前，先把状态转换成一个“纯数据”的形态，只包含基本类型和数组、普通对象。日期转成时间戳或 ISO 字符串，Map 转成数组，函数直接丢弃（因为函数本来也不该是状态）。然后加一个版本号字段，读取的时候先检查版本，不匹配就走迁移逻辑或者直接丢弃。

// 持久化前的清洗 function serializeState(state) { return { version: 2, data: { items: state.items.map(item => ({ id: item.id, name: item.name, createdAt: item.createdAt.getTime() })) } }; }

4. 实操过程与核心环节实现

4.1 从零搭建一个可预测的状态操作层

假设我们要做一个任务管理界面，有任务列表、筛选条件、选中项、编辑弹窗。我按步骤演示怎么设计状态操作。

第一步，列出所有状态，并分类：

第二步，确定修改入口。任务列表的修改有：添加、删除、更新、批量替换。筛选关键词的修改就是设置。选中项就是设置和清空。弹窗就是开和关。草稿就是设置字段和重置。

第三步，实现不可变更新。以更新任务为例：

function updateTask(state, taskId, patch) { return { ...state, tasks: state.tasks.map(task => task.id === taskId ? { ...task, ...patch } : task ) }; }

第四步，实现派生。筛选后的任务：

function selectFilteredTasks(state) { const keyword = state.filterKeyword.trim().toLowerCase(); if (!keyword) return state.tasks; return state.tasks.filter(task => task.title.toLowerCase().includes(keyword) ); }

这里有个细节：派生函数不要每次渲染都全量算，可以用记忆化。判断依赖是否变化，只需要比较state.tasks和state.filterKeyword的引用，因为不可变更新保证了没变就是同一个引用。

4.2 参数选择：缓存策略与更新粒度

状态操作的性能，很大程度上取决于更新粒度。粒度太粗，改一个字段导致整个大树重建，浪费；粒度太细，状态碎片化，管理成本高。

我的经验法则是：按更新频率和依赖关系来切分。更新频率相近、经常一起变的字段放一起；更新频率差异大、依赖方不同的字段分开。比如任务列表和筛选关键词，前者变化少，后者变化频繁（用户每打一个字就变），那就分开存，避免打字的时候重建整个任务列表。

缓存策略上，派生值用记忆化，记忆化的 key 就是依赖的引用。因为不可变更新保证了引用稳定，所以这个判断非常快。如果依赖没变，直接返回上次的结果，连计算都省了。

4.3 实操现场：一次状态不同步问题的排查

说个我实际遇到的案例。有个页面，用户修改了任务标题，列表里更新了，但顶部的“最近修改”区域没更新。排查过程：

先看“最近修改”的数据来源，发现它是单独存的一个状态，在保存任务的时候手动更新的。问题就在这：保存任务有两条路径，一条走编辑弹窗，一条走行内快捷编辑，行内编辑那条路径忘了更新“最近修改”。

修复方案有两个：一是两条路径都补上更新，二是把“最近修改”改成派生值，从任务列表里算出来。我选了第二个，因为派生不可能漏。改完之后，这个 bug 类彻底消失了。

这个案例的教训是：任何需要手动同步的状态，都是潜在的 bug 源。能派生就派生，实在不能派生，也要把同步逻辑收敛到一个地方，而不是散落在各个修改路径里。

5. 常见问题与排查技巧实录

5.1 状态更新了但界面没变

这是最高频的问题。原因通常有三类：

• 引用没变：你直接改了对象属性，但对象引用还是同一个，框架判断“没变化”就不重新渲染。解决：用不可变更新，产生新引用。
• 依赖没追踪到：响应式系统没收集到依赖，或者你读取状态的方式绕过了追踪。解决：检查读取路径，确保在追踪上下文中读取。
• 更新被批处理了：有些框架会把多次更新合并，如果你在更新后立刻读取，可能读到旧值。解决：用更新后的回调，或者接受异步。

排查技巧：在状态修改的地方打日志，在渲染的地方打日志，看修改有没有触发渲染。如果修改了但没渲染，基本就是引用问题；如果渲染了但值不对，就是读取路径问题。

5.2 状态互相依赖导致死循环

A 变了触发 B 更新，B 更新又触发 A 更新，无限循环。这种问题在响应式系统里特别常见。

解决思路：打破循环依赖。要么把互相依赖的两个状态合并成一个，要么引入一个“正在更新”的标志位防止重入，要么把其中一个改成派生值。我一般优先考虑合并或派生，因为标志位是治标不治本。

5.3 状态在组件销毁后还在更新

异步操作回来的时候，组件已经销毁了，更新状态会报错或者造成内存泄漏。解决：在发起异步操作时记录一个“是否已销毁”的标志，回来的时候检查一下。或者用可取消的异步方案，销毁时取消未完成的操作。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑：把派生值也存了一份，结果忘了同步。这个前面说过，教训就是能派生绝不存。

第二个坑：状态更新函数里做了副作用。比如在更新函数里发请求、写日志、改另一个状态。这会导致更新函数不纯，难以测试和追踪。我的原则是更新函数只做一件事：根据旧状态算出新状态，其他什么都不做。

第三个坑：过度使用全局状态。什么都往全局放，结果全局状态膨胀到几百个字段，改一个字段影响一大片。后来我强制自己：只有跨页面、跨组件、生命周期长的状态才放全局，其余一律就近管理。

第四个坑：忽略状态的初始值。状态初始值没设好，导致首次渲染报错，或者出现“undefined”闪烁。我的习惯是每个状态都显式给初始值，哪怕是空数组、空字符串，也不要留 undefined。

6. 状态操作的进阶思路

6.1 用状态机约束状态流转

当状态不是简单的值，而是有明确流转规则的时候（比如订单状态：待支付、已支付、已发货、已完成、已取消），用状态机来管理会比散落的布尔标志清晰得多。状态机的好处是：所有合法流转都定义在一处，非法流转直接拒绝，不会出现“已取消又变成已完成”这种荒谬情况。

实现上，可以定义一个流转表，每个状态列出它能去哪些状态，修改的时候先查表，合法才改。这样状态的合法性有了保障，排查问题也容易，因为任何一次修改都能追溯到是从哪个状态来的。

6.2 状态快照与时间旅行

不可变更新的一个附带好处是，你可以保留历史快照，实现撤销重做、时间旅行调试。做法很简单：每次更新把新状态推入一个历史数组，撤销就是回退指针，重做就是前进指针。因为状态是不可变的，历史快照之间共享大量结构，内存开销并不大。

这个能力在调试的时候特别有用。你可以把每次状态变化都记录下来，出问题的时候回放，看是哪一步改坏的。我有个项目就内置了这个功能，开发环境下可以随时回退到任意历史状态，排查效率提升非常明显。

6.3 状态操作的测试策略

状态操作是纯逻辑，非常适合单元测试。我的测试策略是：每个修改函数和派生函数都写测试，输入旧状态和参数，断言新状态。因为不可变，测试之间不会互相影响，可以并行跑。

测试要覆盖的点：正常修改、边界情况（空数组、空字符串）、非法输入、派生的一致性（派生值等于手动计算的值）。我一般会写一个辅助函数，随机生成状态，然后验证“修改后再派生”和“派生后再修改”结果一致，用来抓那些隐蔽的不一致 bug。

7. 我个人的一些实操体会

State 操作这件事，说到底是在管理“变化”。而变化之所以难管，是因为它打破了我们对“当前值”的直觉。我这些年最大的体会是：不要试图用聪明的方式管理复杂状态，要用笨的方式把状态变简单。能派生的不存，能就近的不全局，能收敛的不分散，能不可变的不直接改。每一条都是在减少状态的数量和修改路径，而状态越少、路径越单一，出问题的概率就越低。

还有一个体会是，状态设计要在写代码之前想清楚，而不是写到一半发现不对再改。我现在的习惯是，动手之前先画一张状态表，列出所有状态、归属、修改入口、派生关系，想清楚了再写。这张表花十分钟，能省后面十个小时的排查时间。

最后分享一个小技巧：如果你不确定一个状态该不该存，就问自己“如果这个值错了，我能从别的地方恢复它吗”。能恢复，就说明它是派生的，不该存；不能恢复，才需要存。这个判断标准我用下来非常准，推荐你也试试。