react 中 ref 是用于访问 dom 节点或组件实例的“逃生舱口”，仅应在必要时（如聚焦、滚动、调用浏览器 api）使用；不应为未来可能的 dom 操作而提前添加 ref，否则违背声明式编程原则，增加维护风险。
react 中 ref 是用于访问 dom 节点或组件实例的“逃生舱口”，仅应在必要时（如聚焦、滚动、调用浏览器 api）使用；不应为未来可能的 dom 操作而提前添加 ref，否则违背声明式编程原则，增加维护风险。
在 React 开发中，ref 常被初学者误解为“获取元素的通用方式”，尤其当开发者具备传统 DOM 操作经验（如 jQuery 或原生 JavaScript）时，容易倾向在每个组件上预设 ref 以备不时之需。但 React 官方明确将其定位为 escape hatch（逃生舱口）：它存在的意义是应对 React 本身未覆盖的底层操作场景，而非替代状态管理或常规交互逻辑。
✅ 推荐使用 ref 的典型场景包括：
- 自动聚焦输入框：
inputRef.current.focus() - 滚动到特定区域：
listRef.current.scrollTo({ top: 0 }) - 集成第三方库（如 Chart.js、Mapbox）需要直接操作 canvas 或 div 元素
- 触发浏览器原生 API（如
getBoundingClientRect()、play()视频方法）
❌ 不应使用 ref 的情况包括：
- 读取或修改组件呈现内容（应通过
state+props实现） - 为事件监听器“找元素”（应使用事件委托或在 JSX 中绑定
onClick等） - 提前为将来可能的埋点、A/B 测试或印象追踪（impression tracking）预留 ref
例如，针对视频缩略图曝光追踪需求，更符合 React 范式的做法是：
将 React 应用升级到最新版本，从类组件迁移到 Hooks，并采用并发特性。用于现代化改造 React 代码库、迁移到 React Hooks 或升级到最新
function Thumbnail({ src, id, onImpression }: {
src: string;
id: string;
onImpression: (id: string) => void;
}) {
const imgRef = useRef<htmlimageelement>(null);
// 使用 IntersectionObserver 替代手动 DOM 查询
useEffect(() => {
const observer = new IntersectionObserver(
([entry]) => {
if (entry.isIntersecting) {
onImpression(id);
observer.unobserve(imgRef.current!);
}
},
{ threshold: 0.1 }
);
if (imgRef.current) {
observer.observe(imgRef.current);
}
return () => observer.disconnect();
}, [id, onImpression]);
return @@##@@;
}</htmlimageelement>
该方案无需在父组件或全局遍历 DOM，也不依赖 CSS 选择器，而是将曝光逻辑封装在组件内部，通过 useEffect 和 IntersectionObserver 实现响应式、可复用的追踪能力——这正是 React “数据驱动视图”理念的体现。
⚠️ 注意事项：
- 不要为每个组件加 ref：批量添加 ref 会显著增加内存开销，干扰 React 的协调（reconciliation）过程，并可能导致 ref 回调频繁触发；
-
避免 ref 与 state 混用：若需响应式更新 DOM 行为，请优先通过
state触发重渲染，而非直接操作ref.current； -
函数组件中统一使用
useRef：类组件中的createRef不推荐用于动态创建多个 ref，useRef更安全可控； -
服务端渲染（SSR）注意：
ref.current在服务端为null，相关逻辑需做空值判断或延迟到客户端执行。
总结而言，ref 不是 React 的“默认配件”，而是有明确边界的底层工具。与其预先埋设 ref，不如在真实需求出现时，结合现代 Web API（如 IntersectionObserver、ResizeObserver）和 React Hooks 设计高内聚、低耦合的解决方案——这既保持了代码的可测试性与可维护性，也真正践行了 React 的设计哲学。
