前言

上一篇我们把 useRef 定义成“持久化可变对象”，最终留了个修改 ref 不触发渲染。这句话是理解 React 数据模型的分水岭，也是面试常考的对比题。

本篇把 useRef 和 useState 放在一起逐项对比。回答三个主要问题：

• 如果我想渲染 ref 里的值，该怎么办？

随后展开 useRef 真正的主战场：那些“不需要渲染但需要共享/清理”的数据。

一、表面差异：返回值与修改方式

先看写法，一眼就能分出区别：

// useState —— 响应式
const = useState
num = // ❌ 不能直接改。必须走 setNum
setNum // ✅ 改完 → 组件自动重新渲染
// useRef —— 非响应式
const numRef = useRef
numRef.current = // ✅ 直接改 → 不重新渲染

痛点： 很多新人会尝试直接改 state结果页面毫无反应，导致调试时间翻倍。

二、主要差异：是否触发渲染

This is 唯一的本质分界线：

A minimal demo:

function App {
const = useState;怎么说呢，const numRef = useRef;return (
<>

{count}
{/* setCount 后这里会变 */}

{numRef.current}
{/* current++ 后这里纹丝不动 */}
);}

The rendering pipeline is: **状态变了 → 重新渲染 → 重新执行组件函数体**。老实说，#setState 会通知 React “该重画了”。而对 #ref.current` 的修改是偷偷进行的，React 根本不知道。

三、更新时机：异步 vs 同步

function App {
const = useState;const numRef = useRef;const click = => {
setNum;console.log，// ❗️setState 是异步的，这里仍是旧值
numRef.current += 1;console.log，不过，// ✅ref 同步生效，立刻得到新值
};怎么说呢，}

• #useState 是异步批处理： 同一次事件里的多次 #setState` 会被合并。导致立即读取到旧值，
• #useRef 是同步的： #current` 改完即刻生效，可立即在同一回调中使用。

Pain point： 在「点击后立刻取最新计数」的业务场景里如果误用了 #useState ,常会出现「页面数字滞后一帧」的问题。

四、相同点

五、要渲染 ref 的值怎么办：三个方案

#useRef 本身没有触发渲染的能力，所以 “渲染它” 必须借助其他机制。下面从最简单到最正规列出三种做法。

至于方案一，直接改用 #useState

 const = useState;

setNum}> { num } < / div>
这是最正确的做法。**要展示在 UI 上的状态** 应该交给 `useState` 管理，一行代码搞定。

说到方案二，#useRef + 强制刷新 
 const num Ref= use Ref;const = use State;其实，// 不关心具体值。只借它的 “刷新” 能力

{
num Ref . current +=1;force Render;// 手动告诉 React ：请重新渲染
}}> { num Ref . current } < / div>
思路是 **两件事分开做** ：`ref` 持久化数据，`state` 用来触发 UI 更新。缺点是每次改 `ref` 都必须记得调用 `forceRender`，容易遗漏。

方案三的观点是，封装成自定义 Hook 
 function useReactive Ref {
const ref= use Ref;老实说，const = use State;const set==>{
ref . current = newVal;force Render;}，return;怎么说呢，}
// 用法类似于 use State
const = use Reactive Ref;

set Num}> { num Ref . current } < / div>

什么情况下值得 “ref + forceRender” 而不用纯 useState？
**真实场景**：既要 UI 跟随变化，又要在异步逻辑里随时拿到最新值。例如定时器每秒累加：
jsx
const count Ref = use Ref;const = use State;useEffect=>{
const id=setInterval=>{
count Ref . current +=1;// 后台逻辑放心改，闭包里永远拿最新值
force Render;// 页面同步显示
},1000);
return=>clearInterval;},)，纯 `useState` 时定时器闭包容易捕获「旧」状态，引发 **闭包陷阱**——此时 `ref` 能保证读取到 **最新** 的数值。

六、#useRef 的真正主战场：四个经典用途 

操作 DOM 是 #useRef 的入门示例。它本质是 “持久化可变盒子”，实战中更常见以下场景。

从用途一来看，存定时器 ID。方便清理 
 function Timer{
const timer Ref= use Ref;const start==>{
timer Ref . current=set Interval=>console.log,1000);}，const stop==>{ clear Interval;}，// 组件卸载时兜底清理
use Effect=>=>clear Interval,);说起来，}
**为什么不用普通变量？** 因为 **ID 不需要触发 UI 更新，却必须跨多次 render 与多个回调共享**——这正是 `useRef` 擅长的领域。

说到用途二，保存“上一次的值”。做对比 
 function App{
const = use State;const prev Count Ref= use Ref;use Effect=>{ prev Count Ref . current=count;})，return 

现在是 {count}，之前是 {prev Count Ref . current}
}
这是官方文档推荐的“上一次状态快照”技巧。

再看用途三，存“最新值”，解决闭包过期问题 

至于闭包陷阱示例。
 function App{
const = use State;use Effect=>{
const id=set Interval=>{ console.log;},1000)，// 永远打印第一次的 count
return =>clear Interval;},)，}
**解决办法 – 用 ref 转发最新值**：
jsx
function useLatest{
const ref = useRef;ref.current = value;// 每次 render 都同步到 latest
return ref;}
function App{
const = use State;const latestCount = useLatest;// latestCount.current 永远是最新
use Effect=>{
const id=set Interval=>{ console.log;},1000)，return =>clear Interval;},)，老实说，

}


原理正是第三节提到的 ref 同步更新——每次 render 把最新数写进 ref.current异步回调读取永远得到最新。

说到用途四，存“一次创建、不能重复”的重对象实例 
 function App{
const worker Ref = use Ref;
// 创建一次昂贵资源，例如 Web Worker
use Effect=>{
const worker=new Worker);worker Ref . current=worker;return =>worker.terminate;// 卸载时关闭线程防泄漏
},);const handleClick==>{ worker Ref . current.postMessage;}，

典型案例包括 Web Worker、WebSocket、AudioContext、第三方库实例等——这些对象创建代价大且需手动销毁，用 useEffect + useRef 能确保：


创建仅一次；

跨 render 持久保存；

在组件卸载时统一清理。


小结 


#useRef 与 #useState 都是 Hook，都能跨 render “记住” 数据；唯一本质不同点是 **改完是否触发重新渲染** —— 响应式 vs 非响应式。老实说，

#useState 异步批处理、只能通过 setter 修改；#useRef 同步生效、直接操作 `.current`。

If you need to display value on UI – go with `.useSt ate`；说起来，If you just need a mutable container – `.u seR ef` plus optional manual refresh.

#UseRe f 的实战主场：


- 定时器 ID / 外部句柄清理；

- 保存上一次状态快照；

- 保存最新值以破除闭包陷阱；

- 持久化“一次创建、多次使用”的重对象实例。These scenarios share common trait: *不需要渲染，但需要持久化/共享/清理*。






Pain point： 切勿在组件函数体内部直接读写 `ref` —— 那样会导致“渲染结果不确定”、难以排查的 bug。