写在前面
从事 React 开发三年，从类组件全面迁移到函数组件 + Hooks 开发模式后，useState 与 useEffect 几乎是每一个业务组件的基础核心。这两个 API 看似简单、上手零门槛，却是日常开发中 bug 高发区。
很多新手甚至资深开发者，都会频繁踩坑：闭包导致的状态陈旧、依赖数组写错引发无限循环、副作用不清理造成内存泄漏、状态更新不及时等问题。本文不堆砌官方文档基础概念，完全基于三年实战踩坑经验，实事求是复盘高频误用场景、底层原因、正确写法。
先厘清核心：两个 Hook 的本质定位
很多人踩坑的根本原因，是混淆了两个 Hook 的核心职责，凭直觉写代码，违背了 React 的渲染逻辑。
为函数组件创建响应式状态，调用 set 函数只会触发组件重渲染，不会立刻修改 state 值。state 的更新是异步、批量的，且每一次渲染都会生成一份独立的 state 快照。
state = 渲染快照 · 异步 · 批量
纯函数组件要求渲染过程无副作用，所有异步请求、定时器、事件监听、DOM 操作、订阅等必须放在 useEffect 中。执行时机与次数完全由依赖数组决定，同时支持清理函数销毁副作用。
effect = 数据变化后的逻辑
useState 高频坑点全解析
从状态更新的本质出发，拆解三类最常见的状态管理陷阱。
连续 setState，状态不叠加更新
业务中需要连续多次更新同一个状态，比如连续累加、批量修改数据，直接多次调用 set 函数，最终状态只生效最后一次。
const [count, setCount] = useState(0) const addMore = () => { setCount(count + 1) setCount(count + 1) setCount(count + 1) } // 执行后 count 只 +1，而非预期的 +3
const addMore = () => { setCount(prev => prev + 1) setCount(prev => prev + 1) setCount(prev => prev + 1) } // 使用函数式更新，基于上一次最新状态计算
React 的 state 更新是批量异步更新，同一渲染周期内所有 setState 会合并执行。三次 setCount 捕获的都是当前渲染快照中同一个旧 count 值，最终只会覆盖生效一次。
但凡新状态依赖旧状态，一律用函数式更新，这是规避状态更新失效的核心原则。
直接修改 state 引用类型数据
修改数组、对象等引用类型 state，直接原地修改，不触发重渲染，视图无更新。
const [list, setList] = useState([1,2,3]) const addItem = () => { list.push(4) // 原地修改原数组 setList(list) // 引用地址不变 } // React 判定无更新，视图不刷新
const addItem = () => { setList(prev => [...prev, 4]) } // 遵循不可变数据原则 // 返回新引用的数据
React 状态更新靠引用地址对比（Object.is），原地修改引用类型数据，引用地址不变，组件不会触发重渲染。这是 React 性能优化的基础机制，也是新人最常踩的坑。
认知误区：setState 后立刻获取最新 state
无数次调试踩坑：在 setState 后紧接着打印 state，永远拿到旧值。很多新人会误以为是框架 bug，实则是时序问题。
const [count, setCount] = useState(0) const handleClick = () => { setCount(count + 1) console.log(count) // 仍是 0 }
// 方案一：useEffect 监听 useEffect(() => { console.log('最新 count:', count) }, [count]) // 方案二：函数式更新回调 setCount(prev => { const next = prev + 1 console.log('最新:', next) return next })
setState 不会立刻修改当前渲染的 state，只会标记更新、等待下一次重渲染。当前渲染周期内，所有 state 都是固定快照。需要基于最新状态执行逻辑，要么用 useEffect 监听状态变化，要么用函数式更新的回调逻辑。
useEffect 核心深坑：三年高频翻车场景
useEffect 是 Hooks 中最灵活、也最容易出错的 API，90% 的 Hooks bug 都出自这里。
核心集中在闭包陷阱、依赖数组误用、副作用不清理、异步竞态问题四大场景。
闭包陷阱（陈旧状态问题）
这是 React Hooks 最经典、最高频的问题，也是最难排查的隐形 bug。
函数组件每一次重渲染，都会生成全新的函数实例和全新的 state/props 快照。useEffect 回调会闭包捕获当前渲染的静态变量，渲染更新后，回调内的变量永远是旧快照的值，无法获取最新状态。
const [count, setCount] = useState(0) useEffect(() => { const timer = setTimeout(() => { console.log('当前 count：', count) }, 3000) return () => clearTimeout(timer) }, []) // 空依赖，闭包锁死 count=0 return <button onClick={() => setCount(prev => prev + 1)}>+1</button>
// 方案A：精准补齐依赖 useEffect(() => { const timer = setTimeout(() => { console.log('当前 count：', count) }, 3000) return () => clearTimeout(timer) }, [count]) // 加入 count // 方案B：useRef 穿透闭包 const countRef = useRef(count) useEffect(() => { countRef.current = count }) // 定时器内读 countRef.current
useEffect 依赖为空数组，仅在组件挂载时执行一次，闭包捕获了初始渲染的 count=0。后续重渲染更新 count，不会重新执行 effect，定时器内永远是旧值。
依赖数组的三大误用场景
依赖数组是 useEffect 的开关，绝大多数 bug 都源于依赖写错。三年实战总结三个绝对避坑点：
依赖缺失：必要变量不写进依赖
useEffect(() => { fetchUserInfo(userId) }, []) // 缺失 userId 依赖
useEffect(() => { fetchUserInfo(userId) }, [userId]) // 完整声明
核心准则：所有 effect 内部使用的响应式变量（state、props、函数），必须全部写入依赖数组。不要凭主观判断「不需要更新」，框架的渲染时序永远优先于主观认知。
依赖冗余：写入频繁更新的引用类型
useEffect(() => { fetchData() }, [{ id: 1 }]) // 每次渲染新对象
const { id } = params useEffect(() => { fetchData(id) }, [id]) // 基础类型稳定 // 函数用 useCallback 缓存 const handler = useCallback(() => {}, [])
空依赖滥用：妄图一劳永逸
很多新人默认空依赖 [] 只执行一次，盲目使用。但空依赖仅代表挂载执行、卸载清理，后续重渲染绝不更新，极易造成状态陈旧、逻辑失效。需要根据变量更新时机精准配置依赖。
副作用不清理，导致内存泄漏、重复执行
useEffect 的第二个核心能力是返回清理函数。定时器、监听事件、网络请求、订阅等，不清理必然引发 bug，这是线上高频报错点。
定时器未清理：叠加执行、内存泄漏
useEffect(() => { setInterval(() => { console.log('定时执行') }, 1000) }, []) // 无 return 清理
useEffect(() => { const timer = setInterval(() => { console.log('定时执行') }, 1000) return () => clearInterval(timer) }, [])
网络请求未处理卸载：组件卸载后 setState 报错
useEffect(() => { const controller = new AbortController() const signal = controller.signal const getData = async () => { const res = await fetch('/api/list', { signal }) } getData() return () => controller.abort() }, [])
清理函数执行时序误区
清理函数不是只在组件卸载时执行。当 effect 依赖更新、重新执行时，会先执行上一次的清理函数，再执行本次新的 effect 逻辑。这个时序是解决重复请求、定时器重置的核心关键，绝大多数人理解错误。
异步请求竞态问题
业务中高频场景：搜索框输入联想、分页切换请求，快速操作时，后发请求先返回、先发请求后返回，导致数据覆盖、展示错乱。
useEffect(() => { fetchData(keyword).then(res => { setList(res) // 可能是旧结果 }) }, [keyword]) // 用户输入 "a" → "ab" // "ab" 先返回，"a" 后返回 // 最终展示 "a" 的结果
useEffect(() => { const controller = new AbortController() fetchData(keyword, { signal: controller.signal }).then(res => setList(res)) return () => controller.abort() }, [keyword]) // 旧请求被中断，彻底解决竞态
effect 重复执行，旧的异步请求未销毁，新旧请求结果互相覆盖。最优解法：结合 AbortController 中断旧请求，确保只有最新请求生效。
三年实战总结：黄金使用准则
结合无数次调试、线上 bug 复盘，总结出一套可直接落地的规范，覆盖 99% 业务场景。
新状态依赖旧状态，必用函数式更新。
引用类型状态严格遵循不可变原则，返回新引用。
异步逻辑优先放 useEffect，不要在 setState 后立刻读取。
不存可计算的派生数据，减少冗余重渲染。
渲染逻辑、纯计算逻辑绝不放入。
遵循 ESLint 规则，不手动省略、伪造依赖。
定时器、请求、监听、订阅一律配置清理逻辑。
根据变量更新时机精准配置依赖。
异步请求必做中断处理，规避竞态和卸载报错。
写在最后：Hooks 的核心思维
三年 React 开发最大的感悟：Hooks 没有玄学，所有坑都源于对「渲染快照」和「副作用机制」的不理解。useState 的异步更新、useEffect 的闭包特性、依赖驱动执行，都是 React 渲染机制的必然结果，而非框架缺陷。
很多开发者一味追求高级 Hook，却连最基础的 useState、useEffect 都用不规范。真正的实战能力，不是会写复杂逻辑，而是能精准规避基础陷阱，写出稳定、无 bug、易维护的代码。
吃透这两个基础 Hook，理解渲染快照、闭包、副作用、依赖更新的底层逻辑，就能解决绝大多数 React 业务问题，这是所有 React 进阶的根基。