
我第一次觉得 `useEffectEvent` 真有必要，不是因为看了官方示例，而是因为我手里有一段 effect 已经快被我自己改烂了。

那是一个带实时消息的页面。页面进入时要建立连接，连接成功后要弹通知，通知文案和样式又会依赖当前主题和语言设置。这个功能最早很简单，后面边做边加，最后 effect 长成了一团。

最开始的版本只有连接逻辑：

```javascript
useEffect(() => {
  const connection = createConnection(roomId);
  connection.connect();
  return () => connection.disconnect();
}, [roomId]);
```

后来要加一个“连接成功提示”，于是 effect 里多了主题依赖；再后来国际化接进来，语言也进来了；再往后，页面切换静音状态时，回调里还要顺手读一遍用户设置。

代码还能跑，但问题越来越明显：只要主题切换、语言切换，连接就会跟着重建一次。功能上不是完全错，但体验和日志都开始变脏。开发时你会看到它反复 connect、disconnect，线上偶尔还会导致通知乱跳。

## 当时最难受的是：逻辑都“看起来有道理”

这类 effect 最麻烦的地方，不在于它明显报错，而在于每一项改动都能自圆其说。

主题确实在 effect 里用了，那依赖数组里放 `theme` 看上去没毛病。

语言也确实在回调里读了，那 `locale` 放进去似乎也合理。

可一旦这些值都放进去，effect 的同步边界就已经变了。原本它只该由 `roomId` 控制，现在任何跟通知相关的 UI 信息变化都会触发重连。

我后来才意识到，这种问题本质上不是依赖数组写错了，而是我把两类逻辑混在了一起：

- 一类是“这个 effect 到底什么时候应该重新同步”
- 另一类是“这个 effect 内部某个事件发生时，我希望读取到最新值”

这两件事不是一个层级，但以前我一直拿同一种写法在处理。

## 我一开始尝试过两个老办法，都不太舒服

第一个办法是继续把所有依赖都放齐，接受 effect 重跑。

这样 ESLint 最开心，代码也最“规矩”，但业务上不舒服。因为我不想让主题切换导致连接重建，这就是不符合语义。

第二个办法是把主题、语言这些值塞进 `useRef`。

这确实能绕开闭包旧值问题，也能避免 effect 重跑。可写到后面代码会越来越像在自己维护一个影子状态系统：

- 每次 render 同步 ref
- 回调里读 `ref.current`
- 还得提醒自己别漏字段

它不是不能用，但很难说优雅。尤其是多人协作时，别人看到 `ref.current` 往往得停一下，想想这段逻辑到底想规避什么。

## `useEffectEvent` 解决的就是这条边界

我后来把那段代码改成了这种结构：

```javascript
const onConnected = useEffectEvent(() => {
  showNotification('连接成功', theme);
});

useEffect(() => {
  const connection = createConnection(roomId);

  connection.on('connected', () => {
    onConnected();
  });

  connection.connect();
  return () => connection.disconnect();
}, [roomId]);
```

改完之后，最大的变化不是代码更短，而是语义终于对了。

`roomId` 仍然决定连接什么时候重建。

而 `theme`、`locale` 这种值，不再参与 effect 的同步边界，只在“连接成功这个事件真正发生时”读取最新值。

这一下把我之前一直拧巴的地方解开了。

## 它最适合解决的是“effect 里的事件”

我现在对 `useEffectEvent` 的理解很简单：它不是一个省依赖的捷径，而是用来表达“effect 里发生的事件”。

这个事件有几个典型特点：

- 不是用户点击按钮这种普通 UI 事件
- 是 effect 内部注册、触发的回调
- 回调里想读最新 props 或 state
- 但这些值不该反过来决定 effect 是否重跑

聊天室连接成功通知、定时器自动保存、原生事件监听回调，这些都属于这个范围。

## 一次定时器问题让我更确信它有用

后来我在另一个编辑页里也碰到过类似问题。

页面每隔几秒自动保存草稿。最早写法是把 `content` 放进依赖数组，于是每次输入都会重新建一遍定时器。功能上没错，但逻辑读起来很奇怪。

如果把依赖去掉，又会拿到旧值。

改成 `useEffectEvent` 之后，这段代码终于回到了它该有的样子：effect 只负责创建和销毁定时器，定时器触发时再读最新内容。这个分层一旦清楚，后面任何人接手都容易理解。

## 什么时候我不会用它

我现在也不会把 `useEffectEvent` 到处塞。

如果某个值真的会决定 effect 是否需要重新同步，那它就应该留在依赖数组里。这个边界不能偷懒。

比如：

- `roomId` 变了，连接就该重建
- `url` 变了，请求就该重新发
- `enabled` 变了，订阅就该开关

这些都属于 effect 的同步条件，不该用 `useEffectEvent` 偷过去。

所以我现在会先问自己一句话：

“这个值是影响 effect 是否要重跑，还是只是希望某个回调触发时读到最新值？”

前者进依赖，后者才考虑 `useEffectEvent`。

## 这类 API 真正让我有感的地方

以前写 React effect，我经常有一种感觉：逻辑明明都对，但总要在依赖数组、ref、eslint 规则之间来回妥协。

`useEffectEvent` 让我第一次觉得，React 是在正面承认这类问题确实存在，并给了一个更像“正经写法”的表达方式。

它不是为了炫新 API，而是把以前模模糊糊、只能靠经验处理的边界，正式写进了模型里。

## 写在最后

如果一个 effect 越写越乱，通常不是因为你不会写 Hook，而是它里面混进了不属于同一层的逻辑。

我现在看 `useEffectEvent`，最重要的价值不是“更高级”，而是它逼着你把 effect 里的同步条件和内部事件拆开。一旦这条边界拆清楚，代码会比以前稳很多，也更像人在维护，而不是在和依赖数组僵持。


React useEffectEvent 实战：我是怎么把一个越改越乱的 effect 拆开的


我第一次认真把乐观更新用进 React 项目，不是在点赞按钮这种玩具级例子里，而是在一个内部内容系统的评论区。

那个页面表面上不复杂：用户输入评论，点击发送，评论出现在列表里。需求也很普通，谁都觉得不难。真正把它做进业务之后，问题很快就出来了。

最开始的实现很直白。用户点击“发送”后，按钮进入 loading，等接口返回成功，再把新评论插进列表。逻辑一点都不花哨，但体验非常差。公司内网环境本来就不稳定，再加上评论接口还会顺手做审核、敏感词和通知，正常情况下一次请求经常要几百毫秒，偶尔还会上 1 秒。结果就是用户每次点完发送，页面都像卡了一下。

最烦的是，这种迟钝不是“性能慢”的那种大问题，它更像一种持续的小摩擦。用户会不自觉地点第二次，会怀疑刚刚有没有发成功，会盯着按钮看。你从埋点里也能看到，评论提交后的二次点击率很高，但接口明明没有真正失败。

## 一开始我用的是最常见的临时状态写法

我最早的处理方式其实很传统：

1. 本地先维护一份 `comments`
2. 再维护一份 `isSubmitting`
3. 提交时手动把一条临时评论插进去
4. 请求回来后用真实评论替换掉临时项
5. 如果失败，再把临时项删掉

这套方案不是不能用，问题在于它很快就会长出一堆边角逻辑。

比如：

- 临时评论的 `id` 用什么生成
- 用户连续发两条时，哪条先回来
- 如果接口失败，输入框里的文字要不要恢复
- 列表重新拉取时，临时项和真实项怎么合并

这些东西单看都不大，但它们会让“提交一条评论”这件事越来越像在修一套同步系统，而不是写一个交互。

那次改造到后面，我最大的感受不是“乐观更新可以让页面更快”，而是如果你继续手搓两套状态，迟早会把自己绕进去。

## 真正的问题不是快不快，而是状态到底该由谁来表达

我后来回头看，当时最别扭的点在于：我一边想让界面先表现得像成功了，一边又不想把真实状态提前写死。

这其实是两种状态：

- 用户当前应该看到什么
- 服务器最终确认了什么

以前我把这两层混在一起处理，所以写到后面只能不断补丁。React 的 `useOptimistic` 给我的帮助，不是“提供一个新 Hook”，而是把这两层状态硬拆开了。

你可以先明确地告诉 React：提交中的界面长什么样。然后等真实请求回来，再把真实状态落进去。这个分工一旦清楚，代码会安静很多。

## 我后来是怎么改的

改造之后，我把评论提交拆成两段：

第一段负责立即反馈。用户点发送的那一刻，先用 `useOptimistic` 往列表里加一条带 `pending` 标记的评论，这样界面立刻变化，输入框也能马上清空。

第二段负责异步收口。接口成功后，把服务端返回的真实评论写回去；失败的话，就把这条临时评论回滚掉，并把输入内容恢复出来。

核心写法和官方文档思路差不多，但我在业务里更在意的是三件事：

```javascript
const [optimisticComments, addOptimisticComment] = useOptimistic(
  comments,
  (currentComments, newComment) => [
    ...currentComments,
    { ...newComment, pending: true }
  ]
);

function handleSubmit(text) {
  const tempComment = {
    id: crypto.randomUUID(),
    text
  };

  startTransition(async () => {
    addOptimisticComment(tempComment);
    await saveComment(tempComment);
  });
}
```

第一，临时评论必须能被稳定识别。否则后面失败回滚、成功替换都会很难做。

第二，失败路径不能是“以后再说”。我一开始就是在这件事上吃亏，导致偶发失败时列表里会留下幽灵评论。

第三，乐观更新最好局部做，不要一上来改整个页面的共享状态。那次我只把评论列表这一段先改了，没有顺手去动评论数、消息中心、右侧推荐这些联动区域。事实证明这是对的，因为局部先跑通以后，边界会清楚很多。

## `startTransition` 在这里帮我的，不是“异步”，而是优先级

很多人第一次看到 `startTransition`，会下意识把它理解成异步包装器。实际开发里我更把它当成“让 React 知道这次更新不必抢最高优先级”。

像评论提交这种交互，用户最在意的是：

- 按钮点下去立刻有反馈
- 输入框别卡
- 列表看起来已经变了

至于后面那次真实状态写回，并不是最强实时的那种更新。`startTransition` 的好处就在这里，它不会把所有状态更新一股脑地压到最前面。页面整体的手感会更平顺，不是那种“逻辑都对，但总觉得哪里发沉”的状态。

## 不是所有交互都该乐观更新

那次改造之后，我有一段时间很上头，觉得很多操作都可以乐观一点。后来很快就收住了，因为有些地方用起来确实不合适。

我现在基本用这几个标准判断：

- 成功率高不高
- 失败后能不能自然回滚
- 即时反馈值不值那点复杂度

点赞、收藏、关注、评论追加，这些通常适合。

支付、库存扣减、权限切换、关键配置保存，这些我就会谨慎很多。因为一旦失败，用户看到的不是“界面闪了一下”，而是对系统信任直接下降。

## 这类改造最后给我的一个感受

我后来越来越觉得，前端很多交互问题表面上像是“等待太久”，其实根子在状态建模。

如果你的代码里只有“提交前”和“提交后”两种状态，那你只能让用户等。可真实交互里明明还有一种状态很重要，就是“用户已经做了动作，系统也应该先给反应，但后端还没最终确认”。

`useOptimistic` 的价值就在这里。它不是为了让页面看起来花哨一点，而是让这层状态终于有了正式写法。

## 写在最后

我现在看乐观更新，已经不太把它当作“体验优化技巧”了，更像是一种交互建模方式。

当你明确区分“用户现在应该看到什么”和“服务器最终确认了什么”之后，很多原来看起来只能靠补丁处理的逻辑，都会顺下来。React 这两个 API 好用的地方，不是新，而是它们终于把这件事讲清楚了。


React 中的乐观更新：我是在一次评论交互改造里真正把它用明白的


这半年里我连续碰到过两个 AI 自动化项目，表面上看都很适合做 Agent，最后做出来的路子却完全不同。也是在这两个项目里，我才真正把“Agent 和工作流的边界”想明白。

第一个项目是内部知识处理流程。输入是文档，输出是摘要、标签、结构化字段，再把结果入库。第二个项目是一个运维助手，目标是接收自然语言指令后去查资料、调用工具、生成处理建议。

最开始团队对这两个项目的直觉差不多：都上 Agent 吧，毕竟多步骤、会调用工具、看起来很智能。

后来回头看，第一个项目如果真按 Agent 做，八成会越做越乱；第二个项目如果只做死工作流，又会显得特别笨。这就是我现在越来越在意的判断点：不是任务里有没有模型，而是路径到底稳不稳。

## 第一个项目教会我的，是“很多流程根本不需要自主规划”

文档处理那个项目刚开始时，也有人提议让模型自动决定每一步怎么做。听上去很先进：先读文档，再判断要不要抽摘要、要不要分类、要不要纠错、最后决定怎么入库。

但我们真正把流程梳理完之后发现，这件事根本没那么开放。

它的真实链路其实很固定：

1. 读文档
2. 提取正文
3. 做字段清洗
4. 生成摘要和标签
5. 输出固定结构
6. 入库

这里面真正需要模型判断的，其实只有个别节点，比如分类和摘要；主流程完全是确定的。

我们后来没有做 Agent，而是把主干写成工作流，再在少数节点上接大模型。结果非常稳。日志清楚，失败能重跑，出了问题也知道卡在哪一步。

这次经历让我第一次明确地感觉到：多步骤不等于 Agent。一个任务就算有六七步，只要路径稳定，它本质上还是流程编排问题。

## 第二个项目让我看到，工作流也会有明显上限

运维助手那次就不一样了。

用户会问：

- “帮我看看这个服务为什么最近报警变多了”
- “对比一下昨天和今天的错误日志趋势”
- “如果我要排查支付回调失败，应该先看哪几个系统”

这种任务的特点是目标清楚，但路径不固定。不同问题，第一步就可能完全不同：

- 有的要先搜知识库
- 有的要先查监控
- 有的要先拉日志
- 有的还得根据前一步结果再决定下一步

我们最早也尝试过工作流化，结果非常别扭。因为你很难提前把所有路径都列出来。流程一旦写死，助手就会表现得像一个菜单系统：能做的事都在预设分支里，一旦用户问法稍微拐一点，就开始答非所问。

这时候 Agent 的价值才真正出来。不是因为它“更高级”，而是它确实更适合这种需要边走边判断的任务。

## 我现在判断 Agent 和工作流，基本看三件事

第一，看路径是不是稳定。

如果一个任务 80% 情况都走同样的步骤，那优先工作流。别为了“智能感”把稳定流程交给模型自由发挥。

第二，看失败成本高不高。

如果一步错了会影响订单、权限、资金、客户数据，那主干流程必须尽量写死。模型可以辅助判断，但不该掌握整个执行权。

第三，看任务是否要求探索未知信息。

如果模型需要先去搜、再比对、再决定下一步，甚至中途可能修正原计划，那才更像 Agent。

这三个问题我现在几乎每次都会问一遍，因为它们能很快帮我把“看起来都像 AI 自动化”的需求拆开。

## 很多团队会误把“多步工具调用”当成 Agent

这是我最近最常看到的一个偏差。

有些系统本质上只是：

1. 读输入
2. 调一个接口
3. 调另一个接口
4. 按模板输出结果

这当然是多步，但不等于 Agent。它没有动态规划，也没有真正的路径选择，只是流程比单步长了一点。

如果把这类流程也包装成 Agent，短期可能显得很先进，长期问题很多。因为一旦让模型自由控制原本可以确定的步骤，你就会开始面对一连串新问题：

- 工具参数为什么变了
- 为啥这次少走了一步
- 为什么昨天成功今天失败
- 失败后该从哪儿恢复

这些问题本来可以靠流程约束直接规避。

## Agent 真正难的地方，从来都不是“会不会想”，而是“出了事怎么兜”

这个认知也是我做第二个项目时被逼出来的。

在 Demo 环境里，Agent 往往看起来很聪明。它会拆任务，会总结，还会自己决定先调哪个工具。可一旦进入真实系统，你马上会碰到完全不同的问题：

- 工具返回半结构化垃圾怎么办
- 上一步失败后，状态存在谁那里
- 一个任务执行到一半中断，能不能恢复
- 模型选错工具时，系统能不能兜底

这些问题不是“提示词再写好一点”就能解决的，它们属于工程治理问题。

所以我现在看一个 Agent 系统，会特别关注这些东西：

- 工具是不是封得干净
- 每一步是否可观测
- 中间状态有没有地方落
- 失败后是否能人工接管

这些事情如果没做好，Agent 再能说，也只是一个容易失控的黑盒。

## 后来我越来越接受一种更务实的做法

很多项目其实不需要在“纯工作流”和“全自主 Agent”之间二选一。

更实用的方式通常是：

- 主干流程写死
- 把模型放在少数确实需要语义判断的位置
- 在开放型环节里再放开自主规划

比如文档项目就是工作流主导，分类和抽取节点交给模型。运维助手则是 Agent 主导，但工具权限、执行范围、输出格式仍然受系统约束。

这种做法没有那么“酷”，但很符合真实交付环境。它既不把模型压成死模板，也不把可控性一把丢掉。

## 写在最后

我现在对 Agent 和工作流的看法已经很简单了：稳定路径别装成智能，自由探索也别硬写成流程。

很多项目不是做不出 AI，而是选错了自动化层级。主干应该被写死的地方，就老老实实写死；真正需要模型判断和规划的地方，再给它空间。边界一旦分清，系统会比“全都交给模型”稳得多，也比“什么都手搓流程”灵活得多。
