按理说，

useEffect 从不关心自己为什么在执行。不过，挂载也好、更新也罢——回调照跑不误。于是「设置已保存 ✓」的 toast 在页面刚加载时就跟使用者打了个招呼。autosave 把一个没人碰过的表单 POST 了出去，埋点上报了一次「变更」——只是组件出现了而已。你想表达的是这个值变化时执行；你实际写出来的是这个值变化时执行，对了开头再无缘无故执行一次。

@reactuses/core 的 useUpdateEffect 就是去掉挂载那一次的 useEffect签名完全一致。cleanup 语义完全一致，恰好跳过一次调用。实现只有四行，所以这篇文章会讲清这四行做了什么、这层抽象唯一真正漏气的地方——React StrictMode。我们会用测试证明开发模式下回调确实会在挂载时触发——还有那几个容易和它搞混的邻居 hooks。TypeScript 优先。说起来，

手写的守卫这方面。痛点一览

跳过挂载执行没什么玄学——任何有点年头的 React 代码库里都有这段：

function SearchFilters {
const isFirst = useRef;useEffect => {
if {
isFirst.current = false;return，}
trackEvent;// 页面加载时别上报，拜托
},);// ...
}

它能用。问题不在正确性，在于这个守卫是每个 effect 一份的：ref、判断、翻转。每个需要这行为的 effect 都要重新敲一遍，而真正的意图——「跳过挂载」四个字——被六行仪式感埋住了。这份配方的各种变体还会在 code review 里慢慢腐烂：有人把标志「简化」成 ,白买一次渲染；怎么说呢，有人把守卫复制进第二个 effect 却让两个 effect 共享一个 ref。于是谁先执行谁消耗掉那次跳过另一个照样在挂载时触发。其实，

使用者痛点：

• Toast/埋点误弹： 页面刚加载就弹出成功提示或上报事件。看起来像 bug，
• Autosave/网络请求误发： 表单未被编辑就立即 POST 或 GET，浪费带宽和服务器配置资源。
• 代码重复与维护成本升高： 每个需要此逻辑的组件都要复制粘贴相同代码，导致难以统一管理和升级。按理说，
• 调试困难： 多处守卫可能相互冲突。让排查谁真的触发导致 bug 更加棘手。

useUpdateEffect —— 去掉挂载的 useEffect

import { useState } from 'react';
import { useUpdateEffect } from '@reactuses/core';function EditorSettings {
const = useState;useUpdateEffect => {
saveSettings;toast，},);return ;说起来，}

M ount 时：什么都不发生——没有幽灵保存。没有对着使用者还没碰过的表单弹 toast。不过，之后每次 settings 变化：和 useEffect

签名与行为完全等同于 useEffect

Signature:

function useUpdateEffect: void;不过，

Behavior: 依赖数组、effect 返回的 cleanup 函数。全按你的直觉运作，没有任何新东西要学——这正是它意义所在。按理说，

四行代码。一个原语：实现细节剖析

createUpdateEffect 工厂函数

const createUpdateEffect = => => {
const isFirstMount = useFirstMountState;hook => {
if {
return effect;}
},deps)，};不过，export const useUpdateEffect = createUpdateEffect;

原语的观点是，useFirstMountState

export const useFirstMountState = : boolean => {
const isFirst = useRef;if {
isFirst.current = false;return true，}
return isFirst.current;}，

• 注意1： effect 本身在挂载时仍然会跑。 React 按常规注册它、diff 并调度回调，被跳过的是里面你的函数。这代表着依赖数组从第一次渲染起就是活跃状态；第二次渲染 diff 时才有真实可比对象。
• 注意2： createUpdateEffect 是工厂。只要换 hook 就能得到对应版本，例如用 `useLayoutEffect` 得到 `useUpdateLayoutEffect`。怎么说呢，
• Cleanup 行为： 第一次更新前没有 cleanup；若至少跑过一次则后续更新或卸载都会正常触发 cleanup。这一点通过库自测严格保证。

---