第二种是实例变量。当你用 useRef 来存储定时器 ID、或者某个不需要触发重渲染的状态时这个 ref 完全由你掌控。你想怎么改就怎么改，所以它应该是“可变”的。

听起来hen完美，对吧？通过类型系统来防止开发者误操作 React 管理的引用，这简直是类型安全的典范。但现实往往比理论要骨感得多。

为了实现这种区分，React 的类型定义中埋下了一套非常复杂的重载逻辑。TypeScript 编译器会像侦探一样，根据你传入的初始值和泛型参数，来推断这个 ref 到底属于哪一类。

这就导致了一个非常微妙的情况。Ru果你写 useRef，你传递了一个 null 作为初始值，但在泛型参数里并没有明确包含 | null。在 React 的旧逻辑kan来这传递了一个信号：你想要一个指向 DOM 元素的引用，而且初始值是空的。既然是 DOM 引用，那就归 React 管，那就得是 readonly 的。

于是RefObject 接口中的 current 被标记为了 readonly。这直接导致了前文提到的那个赋值错误。你明明拥有这个对象的引用，却因为类型定义的“过度保护”，失去了修改它的权利。

Ru果这只是个人项目中的小插曲，那也就罢了。但随着 React 生态的繁荣，这种设计开始阻碍基础设施的建设。Zui典型的例子就是组件库中的 forwardRef 和 Ref 合并逻辑。

想象一下你在开发一个 UI 组件库。你需要把父组件传进来的 ref 和组件内部自己用的 ref 合并在一起，以便同时暴露给外部和内部使用。这是一个非常标准且必要的需求。你可Neng会写一个类似 useCombinedRefs 的工具函数：

export const useCombinedRefs =  => {
  return useCallback => {
    refs.forEach(ref => {
      if  return;
      if  {
        ref;
      } else {
        // 这里！这里就是战场！
        ref.current = element; 
      }
    });
  }, refs);
};

在旧有的类型定义下ref.current = element 这一行代码会疯狂报错。因为 TypeScript 认为 ref 可Neng是一个 RefObject，也就是只读的。你无法保证外部传来的 ref 一定是可写的，你也无法强制所有调用方dou按照你的意愿去定义泛型。

这导致了一个荒谬的现状：为了写出类型正确的代码，组件库开发者不得不大量使用类型断言，或者绕过类型检查。原本旨在“确保正确使用”的设计，反而成了阻碍正确使用的绊脚石。

其实关于这个问题的讨论从未停止过。早在几年前，就有开发者在 GitHub 上提出质疑，认为这种区分在 JavaScript 的世界里显得水土不服。有人建议，Ru果 useRef 没有传初始值，就默认当作是 JSX 引用；Ru果传了初始值，就当作是实例变量。

这个建议听起来hen符合直觉，但hen快就被否决了。因为早期的文档中充斥着不带初始值的 useRef 用法，Ru果贸然改变语义，破坏性太大。而且，

当时React 团队中也有成员坚定地维护 readonly 的设计。他们认为，这是一种优雅的约束，Neng防止开发者犯下“在 React 管理的 ref 上乱写数据”的错误。Ru果你真的需要一个可写的 ref，并且初始值是 null，那你就在泛型里老老实实加上 | null，比如 useRef。这样 TypeScript 就会根据“Zui佳匹配原则”，返回一个 MutableRefObject。