React useEffect对象监听：依赖数组原理与五种可靠方案

1. 先看现象：useEffect到底能不能监听对象

这个问题几乎是所有React开发者绕不过去的一道坎，社群里隔三差五就有类似的提问：“我useEffect的依赖数组里传了一个对象，为什么改了里面的属性却不触发？”“为什么我传了对象进去，结果每次渲染都在执行effect？”老实说，这类问题一点都不丢人，因为 React 的 useEffect 在对象监听这件事上，表现得确实足够反直觉，而这个反直觉恰恰藏在依赖比较的底层机制里。

先用一句话把结论摆出来：useEffect本身不提供“对象属性深度监听”能力，它只会在渲染结束后，拿依赖数组里的每一个值与上一次渲染时的对应值做一次“浅层比较”。比较的方法不是深比较，也不是JSON序列化后比对字符串，而是JavaScript里最底层的同值比较（Object.is）。所以当你把一个对象字面量放进依赖数组时，每次渲染都产生了一个全新的对象引用，从React的视角看，这等于依赖变了，于是effect每次渲染后都会执行。如果你把同一个对象的某个属性拆出来作为依赖，那这个属性如果是基本类型，React能准确感知到它变化了；如果属性本身又是对象或数组，那又回到引用比较的怪圈。

那是不是意味着“useEffect不能监听对象”这个说法完全正确？也不尽然。更准确的说法是：useEffect不能直接、直观地深度监听对象内部的变化，但可以通过各种变通手段实现“对象内容变化时执行副作用”的真实需求。这篇文章会把背后的原理、常见的五种方案、以及我踩过的坑全部摊开讲清楚，力求你看完之后能彻底搞明白这个问题，以后再遇上类似的代码心里有底，不再靠“试一下不行就换一种”的方式瞎碰。

2. 理解依赖比较：React怎么判断依赖变了没有

2.1 Object.is比较规则：基本类型和引用类型的差异

要理解useEffect的行为，绕不开JavaScript里的“值比较”。React官方文档明确说了，effect的依赖比较用的是 Object.is 算法，这个算法和常用的 === 基本一致，只有两个边界情况不同：Object.is(NaN, NaN) 为 true，Object.is(+0, -0) 为 false。在绝大多数业务场景里，你完全可以把它当成 === 来看待。

问题就出在这里：=== 比较基本类型时比较的是“值”，例如 1 === 1 成立，'hello' === 'hello' 成立；但比较对象时比较的是“引用”，只有两个变量指向内存中的同一个对象时才相等。所以哪怕两个对象的内容完全一样，只要它们是分别创建的，它们就不相等。

这带来的直接后果是：只要组件重新渲染，函数体重新执行，里面写的字面量对象{ name: '张三' }就是一个全新的对象，它在内存中的地址和上一次渲染产生的对象完全不同。放在依赖数组里，React 一比较发现“两个对象不相等”，自然就认为依赖发生了变化。

2.2 一个典型案例：为什么它每次渲染都执行

我们来做一个实际验证，先看这段代码：

import { useEffect, useState } from 'react'; function UserProfile({ userId }) { const [user, setUser] = useState({ name: '张三', age: 18 }); useEffect(() => { console.log('effect执行了，当前user：', user); }, [user]); return ( <div> <p>{user.name} - {user.age}</p> <button onClick={() => setUser({ ...user, name: '李四' })}> 改名 </button> </div> ); }

当页面首次加载时，effect执行一次，这没问题。点击“改名”按钮后，我们通过 setUser 传入了一个新对象，触发重渲染，effect再次执行，这符合预期。但如果你在父组件里添加一个不相关的状态更新，让 UserProfile 跟着重渲染，情况就不对了：

function App() { const [count, setCount] = useState(0); return ( <div> <button onClick={() => setCount(count + 1)}>count: {count}</button> <UserProfile userId={1} /> </div> ); }

每次点击count按钮，App重渲染，UserProfile作为子组件也重渲染。重渲染过程中，useState({ name: '张三', age: 18 })这一行虽然写在组件外面？不对，写在里面，但 useState 的初始值只在首次渲染时使用，后面重渲染它不会重新赋初值。可是注意，组件函数体里如果还有别的地方在构造对象，那每次重渲染都会重新构造。即便user状态本身没变，只要依赖数组里有[user]，而上一次渲染和这一次渲染的 user 确实是同一个引用，React就不会触发effect。

等等，案例里的代码如果user没有变化，[user]引用不变，effect不会重复执行。真正导致“每次渲染都执行”的是另一些写法，比如直接在依赖里写字面量对象，或者在每次渲染中创建新对象传给子组件，子组件的effect依赖这个对象，才会每次都执行。

我改一下更典型的案例：

function Child({ data }) { useEffect(() => { console.log('子组件effect执行'); }, [data]); // data 是父组件每次渲染重新创建的对象 return <div>{data.name}</div>; } function Parent() { const [count, setCount] = useState(0); return ( <div> <button onClick={() => setCount(count + 1)}>count: {count}</button> <Child data={{ name: '张三' }} /> </div> ); }

这里每次点击按钮，Parent都会重新执行，{ name: '张三' }这个对象被重新创建，Child接收到的 data 引用发生变化，于是子组件的 useEffect 每次渲染后都会执。这不代表 React 不工作，恰恰说明 React 的依赖检测机制工作得非常准确，只是它按照“引用是否变化”来判断，而不是“内容是否变化”。

弄清楚这一点，你也就明白了为什么很多老手会反复强调：依赖数组里应该放基本类型、稳定引用、或者用 useMemo/useCallback 包裹后的产物，而不是随手写的对象字面量。

3. “监听对象”的五种正确打开方式

3.1 方案一：拆分依赖，把对象里的基础字段作为依赖项

最简单的思路，也是React官方最推荐的思路：依赖数组里的成员最好是基本类型。如果你要监听的对象结构比较扁平，字段值都是字符串、数字、布尔值这类基本类型，那就把相关字段直接拆出来放进依赖数组。

function SearchPanel({ filters }) { const { keyword, category, pageSize } = filters; useEffect(() => { // 当 keyword、category、pageSize 发生变化时才执行 fetchData({ keyword, category, pageSize }); }, [keyword, category, pageSize]); // 注意：这里没有把 filters 整体放进去 }

这种写法的好处非常明显：effect 只在某个具体字段真的发生改变时执行，不会因为 filters 对象每次渲染都是新引用而反复执行。同时可读性也更好，一眼就能看出这个副作用依赖哪些数据。

但它有个适用边界：对象内部的字段必须是基本类型。如果某个字段本身又是一个对象，比如filters.sort = { field: 'time', order: 'desc' }，那么把这个嵌套对象放进依赖数组，就又回到引用比较的坑里去了。遇到这种场景，可以把嵌套对象里具体需要用到的字段继续拆出来，比如filters.sort.order，但这样依赖数组会越来越长，代码也会有点啰嗦。

还有一个隐藏的坑是：如果你的 effect 里用到了整个 filters 但只拆了部分字段作为依赖，ESLint 的 react-hooks/exhaustive-deps 插件会报警告，提示你可能漏掉了依赖。很多团队是把这个规则当作 error 来配置的，这时候你就要么补全依赖（但可能造成多余执行），要么用注释禁用规则（不太推荐），要么用下面要讲的更合理的方案绕过这个问题。

3.2 方案二：JSON字符串序列化，用字符串做依赖

一种在网上传播很广的做法是把对象序列化成字符串，然后放进依赖数组：

useEffect(() => { // 这里执行你的副作用 loadData(); }, [JSON.stringify(filters)]);

这个方案的本质是：把对象的内容变成字符串，只要对象内容不变，序列化出来的字符串就不变；对象内容变化了，字符串就跟着变。这样 React 在比较依赖时，比较的是字符串（基本类型），自然能准确感知内容层面的变化。

我自己在早期项目里用过这个方案，确实能解决“对象内容变化但effect未执行”的问题，但它有至少三个需要注意的点：

第一，序列化结果受键顺序影响。如果某个操作创建了一个键顺序完全不同的对象，比如{ a: 1, b: 2 }和{ b: 2, a: 1 }，JSON.stringify 的结果分别是'{"a":1,"b":2}'和'{"b":2,"a":1}'，它们不相等，于是 effect 会触发一次本不必要的执行。虽然大多时候不会出问题，但你要知道有这个不确定性。

第二，序列化有性能开销。如果对象很大、字段很多，或者组件渲染很频繁，每次渲染都做一次 JSON.stringify 会把额外的CPU消耗加在渲染路径上。一般业务场景影响不大，但如果是高频更新的动画或实时数据大屏，就要谨慎使用。

第三，无法区分部分类型的值。JSON.stringify 会把 undefined、函数、Symbol 忽略掉，会把 NaN 转成 null，Date 对象会转成 ISO 字符串。如果对象里含有这些类型的值，序列化后的字符串可能失真。比如{ a: NaN }和{ a: null }序列化出来都是'{"a":null}'，这时候依赖误判就可能发生。

这个方案比较适合“对象结构不复杂、不含特殊类型、键顺序稳定”的场景。作为临时解决手段可以，但不建议在大型项目中全面铺开。

3.3 方案三：用 useMemo 创造稳定引用

如果对象本身是通过计算得来的，而且你不希望它每次渲染都变化，用 useMemo 给依赖“定住”是一个很常见的手段。

function ProductList({ products, filterOptions }) { // 只有当 filterOptions 真的发生变化时，filter 引用才会更新 const filter = useMemo(() => { return { name: filterOptions.name.trim().toLowerCase(), priceRange: filterOptions.priceRange, }; }, [filterOptions.name, filterOptions.priceRange]); useEffect(() => { // filter 是一个稳定引用，内容变化时才会变化 fetchProducts(filter); }, [filter]); }

这个方案的精髓在于：你不在 useEffect 里做过滤或序列化，而是用 useMemo 先把对象处理成一个稳定、可控的引用，只要 useMemo 依赖的基本类型没变，返回的对象引用就不会变。这样放进 effect 依赖数组的 filter，在某些渲染中保持不变，effect 自然不会乱执行；当 filterOptions.name 或 priceRange 变化时，useMemo 重新计算，filter 引用更新，effect 才触发。

这个方案有几个好处：不依赖 JSON 序列化、性能比深比较方案好、代码意图清晰。它把“对象内容变化”这个语义转换成“对象引用的受控更新”，本质上是在利用 React 的渲染机制做事。

需要注意的是，useMemo 不是免费的，它本身也有依赖比较的开销，但和在渲染路径上做深比较相比已经轻量很多。而且 useMemo 缓存的是计算值，如果计算本身复杂，那无论用不用 useMemo 都要付出计算成本，useMemo 只是帮你在依赖没变时跳过重复计算。

3.4 方案四：useRef + 手写深比较，真正意义上“深度监听”

如果前面的方案都满足不了你，比如你需要监听一个深层嵌套对象的内容变化，而且对象结构复杂到没法轻易拆分，那就可以考虑 useRef 存上一次的值，配合深比较函数来决定要不要执行副作用。

import { useEffect, useRef, useState } from 'react'; import { isEqual } from 'lodash-es'; function useDeepEffect(callback, deps) { const ref = useRef(); const signalRef = useRef(0); if (!isEqual(ref.current, deps)) { ref.current = deps; signalRef.current += 1; } useEffect(callback, [signalRef.current]); }

这个自定义 hook 的原理并不复杂：每次渲染时，用深比较函数判断这次传入的 deps 和上次存下来的值是否相等。如果不等，就把内部的一个数字信号加一；如果相等，数字信号保持不变。useEffect 实际依赖的是这个数字信号，而不是 deps 本身，通过这个中转，把“内容是否变化”转换成了“数字是否变化”，避开了引用比较的限制。

使用的时候和普通 useEffect 几乎一样：

useDeepEffect(() => { console.log('深层对象变化了'); }, config);

这个方案的优点是真正做到了内容层面的监听，不管对象嵌套多少层，只要内容变化了，effect 都会执行。缺点是深比较本身有性能和复杂度成本，尤其对大对象、高频渲染场景不友好。而且深比较函数如果处理不了循环引用，还可能直接报错。所以这个方案更适合“小规模、低频、但结构确实复杂”的对象。

自己手写一个轮子没问题，但在生产环境我更推荐直接用 lodash 的 isEqual，或者像 fast-deep-equal 这样专门为速度优化的库，避免实现边界问题。

3.5 方案五：用 useReducer 把“变更”变成显式事件

第四个方案虽然能深监听，但它仍然是一种“轮询式”的比较：React 每次渲染后都要主动比较内容。如果对象更新频率不高，而且你希望对“怎么变了”有更强的控制，可以考虑换一种心智模型——把对象变化建模成显式事件。

const initialState = { name: '张三', age: 18 }; function reducer(state, action) { switch (action.type) { case 'updateName': return { ...state, name: action.payload }; case 'updateAge': return { ...state, age: action.payload }; case 'reset': return initialState; default: return state; } } function Profile() { const [user, dispatch] = useReducer(reducer, initialState); useEffect(() => { // 任何 dispatch 之后，user 引用变化，这里就会执行 console.log('用户信息已更新', user); }, [user]); }

在这个模式下，你不去“监听对象内部的属性变化”，而是把每次更新都当作一次 dispatch 动作。user 对象的引用每次 dispatch 后一定是新的，所以 useEffect 依赖 [user] 是准确且可控的。这其实绕开了“对象内部变化如何被感知”的问题，因为所有变化都必须通过 dispatch 这样的显式入口来发生，React 天然知道变了没有。

有人会觉得这只是在变着法子管理状态，不算“监听”。但从工程视角看，这个方案更符合 React 的设计哲学：状态更新是显式的、不可变的、可追踪的。它不仅解决了监听问题，还顺带让状态管理变得更加严谨和可预测。

如果你的场景是表单、复杂配置，或者有一堆互相影响的状态，用 useReducer 或者类似 zustand、use-merge-state 这样的状态管理工具，通常会比在 useEffect 里反复深比较舒服得多。

4. 从“监听对象”到“记录变化”的思维转换

4.1 你真的需要监听整个对象，还是只需要监听某个值

聊完具体方案，我想跳出代码层面聊聊这个问题的本质。

很多时候我们在问“useEffect能不能监听对象”，背后真正的痛点是：我们希望有一个机制，在某个对象的任意属性变化时都能触发一段逻辑。但 React 的数据流是显式的，组件因状态变化而重渲染，副作用通过依赖数组声明自己依赖了哪些数据。在这个模型里，“任何属性变化都触发”其实是一个范围特别宽、边界特别模糊的需求。

在实践中，我见过很多因为滥用“对象级监听”导致的问题：effect 执行次数不可控、依赖项难以排查、调试时根本不知道哪次更新触发了 effect。相比之下，明确列出你关心的字段，或者用 dispatch 显式描述变化，反而让代码更可控。我经常在代码评审里说的一句话是：如果一个 effect 的依赖项写出来像一篇文章那么长，那你的设计大概出了问题，应该想想是不是把多个副作用混在了一起。

4.2 useEffect 适合处理什么，不适合处理什么

useEffect 本质上是为了处理“渲染后的副作用”：数据获取、订阅、手动修改DOM、日志上报等。它的触发时机是渲染完成之后，而且是异步的（大多数情况下）。如果你需要在用户交互过程中同步响应某些变化，或者需要实时计算派生状态，那更合适的工具是 useMemo、useState 的联动更新，甚至 useReducer 的 reducer 本身。

一个典型的误用是把 useEffect 当成“响应式系统”来用：对象改了，立刻同步执行一些操作。在这种思路下，你期望像一个魔法监听器一样工作，但 React 不是这么设计的。React 的哲学是渲染结果由状态决定，副作用只是附带的后续动作。所以与其费劲让 useEffect“监听”对象，不如反思你的状态变更入口是不是足够清晰。

4.3 从 React 版本演进看官方态度

React 团队其实一直在思考这类问题。React 19 引入了useEffectEvent，用来解决 effect 内部函数的依赖问题，它不是用来替代 useEffect 的，而是让 effect 里调用的“事件型函数”拥有最新值的同时不会触发 effect 重新执行。这个新特性说明官方也在努力让副作用和依赖管理更加直观。

另外，React Compiler（React 编译器）也在持续优化自动缓存，很多依赖不稳定导致的潜在性能问题未来可能被编译器自动处理掉。但无论工具怎么进化，我们自己理解引用比较、依赖声明这些底层机制，依然是很核心的基本功。哪怕未来哪天 React 提供了一个真正深度监听的 hook，理解背后的代价和意义，你才能知道该不该用、怎么用它才不踩坑。

5. 实战排查：我遇到过的三种“监听失效”现场

5.1 现场一：依赖数组塞了对象，却发现 effect 不执行

这个场景特别讽刺，很多人（包括我早期）以为“依赖的对象内容变了，React 就会知道”，但实际经常是：第一次渲染时 effect 执行了，后续不管你怎么改对象的属性，effect 都不再执行，甚至控制台不打印任何东西。

原因很简单，你每次改属性改的是同一个对象引用。比如：

const [user, setUser] = useState({ name: '张三' }); const updateName = () => { user.name = '李四'; // 你直接改了原对象 setUser(user); // 传入的还是同一个引用 }; useEffect(() => { console.log('user变了'); }, [user]);

这里的 user.name 虽然变成了“李四”，但 user 这个对象引用没变，React 比较依赖时发现引用没变，于是不触发 effect。React 的状态更新必须是不可变的：要产生新状态，就得创建新对象。正确做法是setUser({ ...user, name: '李四' })。

这个坑其实和 useEffect 关系不大，更核心的问题是对 React 状态不可变性理解不够。如果你会直接修改 state 对象再塞回 setState，那无论用什么监听方案都救不了你。

5.2 现场二：effect 死循环，页面直接卡死

和“不执行”相反的另一类问题，是 effect 陷入了无限循环。

一个非常常见的死循环写法是：

useEffect(() => { setConfig({ ...config, updatedAt: Date.now() }); }, [config]);

这段代码在 effect 内部更新了 config，config 的引用发生了变化，于是 effect 重新执行，又重新 setConfig，又变化，再执行……无限循环。

这种问题从 React 的角度看没有任何“错误”：你确实声明了依赖 config，而 effect 内部也确实修改了 config，所以它只好一次次执行。但是作为一个有经验的开发者，你需要意识到：effect 不该以它自己依赖的值为输入，去不断修改这个值本身。如果你需要基于某个状态的变化来修改另一个状态，应该考虑在事件处理器里完成，而不是在 effect 里。

如果你确实需要在状态变化后执行一些逻辑，并且这个逻辑会修改另一个状态，建议检查一下设计是否合理，是不是可以用 useReducer 把多个相关状态合并成一个状态对象来管理。

5.3 现场三：期望监听数组变化，但数组元素的属性变化没有被捕获

还有一个常见的场景：你有一个对象数组，比如列表项[{ id: 1, status: 'pending' }, { id: 2, status: 'done' }]，你把它放进 useEffect 的依赖数组，期望“数组里某个元素的 status 变了”时触发 effect。

但如果你更新数组的方式是直接修改某个元素的属性，比如list[0].status = 'success'，然后setList(list)，那数组引用没变，effect 不会触发。正确的方式是创建一个新数组和新对象：

const newList = list.map(item => item.id === 1 ? { ...item, status: 'success' } : item ); setList(newList);

这里的关键是：不仅数组的引用要变，被修改的那个对象的引用也要变。如果数组是新数组，但里面的元素还是旧对象引用，React 使用默认的浅比较看 [list] 时，第一层引用变了就会触发 effect；但如果你把数组拆开监听（比如依赖 list 里的某个字段），那你还需要确保对应字段的引用也变了。

这个案列进一步说明：用 useEffect 监听对象/数组内部变化不是不可能，但你必须清楚自己依赖的到底是什么，是外层引用还是内层某个值。如果只想监听一层，靠引用变化就够；如果要监听深层内容，就需要借助我们前面提到的手段。

6. 最终建议：如何选择合适你的“监听”方案

如果你看完上面的内容有点眼花缭乱，这里给一个快速决策清单，帮你按需选择：

从代码可维护性的角度，我个人最推荐的是“拆分字段依赖”加“useMemo 稳定引用”的组合，这两种方案最贴近 React 的设计方式，心智负担小，也容易通过代码评审。深比较方案可以作为一个工具类 hook 在特定场景使用，但仍建议限制它的使用范围，不要全项目无脑用它替代 useEffect。

再补充一个心得：写 useEffect 的时候，试着把依赖数组想象成一个“声明”，也就是告诉 React 你这段副作用在什么时候需要重新运行。如果你自己都说不太清楚这个副作用依赖了什么，那这段代码大概率是危险的，需要重新设计。

7. 最后的建议：不要为了“监听”而监听

写到这里，我想回到文章开头那个问题：React useEffect 到底能不能监听对象？我的答案是：它能监听对象引用的变化，不能天然监听对象内容的变化，但我们可以通过多种变通手段模拟出内容级监听的效果。

但比这个答案更重要的一句话是：在绝大多数场景下，你其实不该纠结怎么监听对象，而应该思考如何让状态变化变成显式且可控的。React 设计哲学里，状态是数据的源头，渲染是状态的投影，副作用是渲染完成后的附加动作。如果你试图在副作用里做太多“对状态的观察和响应”，这本身就是一个信号，说明你的状态流转可能有更简洁的表达方式。

我在实际项目里的体会是，刚接触 React 的开发者很容易把所有业务逻辑都写在 useEffect 里，搞得组件像一棵长满挂件的圣诞树。后来随着经验增加，你会慢慢学会把逻辑下沉到事件处理器、状态管理工具、自定义 hook 里，useEffect 的数量反而会少很多，代码也更清晰了。所以如果你现在正被“useEffect 能不能监听对象”这个问题困扰，不妨在寻找方案的同时，也退一步看看你的整体设计，也许这才是解决问题的真正钥匙。