虚拟 dom 并非原生 dom 的升级替代品，而是特定抽象层的渲染策略；其运行时开销、控制粒度损失及diff机制限制，使原生dom在首屏静态渲染、高频动画、非声明式交互和超大规模列表等场景中更具优势。
虚拟 DOM 并不是原生 DOM 的“升级替代品”，而是一种在特定抽象层上做权衡的渲染策略。它无法完全取代原生 DOM 操作，根本原因在于：抽象带来便利的同时也引入了不可忽略的运行时开销和控制粒度损失。是否使用、何时让渡控制权给原生 DOM，取决于具体场景对性能、可控性与开发效率的真实需求。
首次渲染大量静态内容时，原生 DOM 更快
页面加载初期，虚拟 DOM 需先将 HTML 结构解析为 JS 对象树（即“挂载”过程），再比对、打补丁、同步到真实 DOM。这个流程本身就有计算和内存开销。而原生 DOM 可由浏览器直接解析 HTML 字符串并构建节点，省去中间映射环节。尤其在 SSR 后首屏直出、或纯展示型后台管理首页等场景中，用 document.createElement + appendChild 手动插入数百个静态卡片，往往比 React 渲染同等 JSX 更快、白屏时间更短。
高频动画与像素级控制需要绕过虚拟 DOM
动画本质是连续、高帧率的样式变更（如 transform、opacity）。虚拟 DOM 的更新机制是批量、异步、基于 diff 的——哪怕只改一个元素的 translateX，也要走一遍 vnode 重建 → diff → patch 流程，可能错过关键帧。而原生 DOM 配合 requestAnimationFrame 和 Element.animate() 或 CSS @keyframes，能实现零延迟响应与硬件加速。例如拖拽排序、实时画布标注、滚动视差等，通常需在 ref 上直接操作 style.transform 或调用 getBoundingClientRect()，这些动作天然游离于虚拟 DOM 生命周期之外。
动态 DOM 结构或非声明式交互依赖原生能力
某些功能无法被“状态驱动”的声明式模型覆盖：比如监听 document 上的全局 click 实现菜单自动收起；用 Range 和 Selection API 实现富文本光标定位；或通过 IntersectionObserver 主动观测元素可视状态来触发懒加载逻辑。这些操作不源于组件 state 变化，也不生成可 diff 的 UI 输出，而是对 DOM 生态的主动探查与干预。强行塞进虚拟 DOM 模型，要么增加冗余 re-render，要么被迫用 useEffect / mounted 做副作用桥接，反而模糊了关注点。
超大规模列表的局部更新可能得不偿失
当单页承载上万条数据且支持实时增删/搜索/排序时，虚拟 DOM 的 diff 算法（即使带 key）仍需遍历整个列表 vnode 树。此时，原生 DOM 配合 DocumentFragment 批量插入、element.replaceChildren() 替换子节点、或用 virtual scroller 库只渲染可视区域 DOM，往往比“全量 re-render + diff”更轻量。Vue 的 v-memo 或 React 的 useMemo + useCallback 能缓解，但无法消除 vnode 创建与比对本身的固定成本。
不复杂但容易忽略：虚拟 DOM 是工具，不是教条。框架封装的是通用路径，而业务现场永远有特殊路径。真正成熟的前端工程，是在声明式主干上，自然嵌入必要的命令式毛细血管——该用 ref.value.style 就用，该调 getComputedStyle 就调，该写 innerHTML = htmlString 也不必愧疚。关键在清楚每一行代码落在哪一层：是描述“要什么”，还是解决“怎么要”。
