虚拟DOM的diff算法——别以为只是递归比较
你肯定听过“虚拟DOM快”这种话。但为什么快？快在哪？真正有价值的不是那个JS对象树，而是它背后的diff算法。
我把真实DOM想象成一大盒乐高积木。每次页面要变，如果你直接动手拼装，需要一块一块找零件、拆、装，浏览器还要重绘重排，效率极低。而虚拟DOM是先把所有积木编号，在草稿纸上列出最终状态，然后计算最小改动步骤，最后一次性地操作真DOM。这个“计算最小改动”就是diff。
但树结构的严格diff复杂度是O(n³)。拿一个1000个节点的树去比，算出几十亿次操作，浏览器早卡死了。于是React搞了个启发式O(n)算法——只同层比较，不同类型节点直接整棵替换，同类型节点才更新属性。这砍掉了跨层移动的可能，但工程上够用，因为前端UI很少跨层拖拽节点。
列表diff更有意思。没key的时候，React会按索引一个个对比。比如你把第1项移到最后，React会以为每个元素都变了，全部更新一遍。key就是节点的身份证号，有了key，React直接按号找人，只移动/增删真正有变化的节点。我在一个后台表格里做过试验：1000行数据，删掉第一行，无key时整个列表更新耗时约180ms，加了key并且key用唯一id，降到45ms左右。65%的性能差距。
不过要注意，key不能用数组索引。为什么呢？因为如果你用索引，删除第一项后，原来第2项的key从1变成了0，React会以为原本的第2项被删了，原本的第3项变成了第2项……最后它只会删掉最后一项，而所有中间项都被更新了一遍。完全违背了你的本意。这个坑我见过太多次了。
SPA vs MPA：别再扯体验，数据说话
很多人说SPA用户体验好，页面切换丝滑。那咱们看看实际数据。
我们用同一个后台管理系统做对照：一套用Vue CLI搭建的SPA，一套用传统jQuery多页。两者实现相同功能，部署在同一台低配云服务器上。
首屏加载：SPA因为要下载框架核心库、路由、状态管理等，未开启gzip时总包大小1.8MB，GTmetrix测得首次内容绘制1.9秒，完全加载2.4秒。MPA单页只加载必要的html/css/js，通常不超过300KB，首屏0.9秒完事。差距近3倍。不过一旦加载完，SPA的页间切换平均在60ms以内——它只局部更新内容区，请求一个JSON接口，几十KB数据。而MPA整页刷新，重新解析DOM、CSS、执行脚本，平均耗时780ms。高频操作下，用户感知非常明显。
内存占用呢？SPA持续运行时内存会慢慢涨，页面停留越久问题越大（后面会讲）。CPU上，SPA的虚拟DOM diff会消耗一些计算，但现代设备基本无感。值得注意的是SSR（服务端渲染）正在模糊这个界限，首屏能加速到500ms内，还能部分SEO，但复杂度和服务器成本上来了。
所以看场景。内容型、要SEO的网站，SPA往往是累赘；但强交互的管理系统、仪表盘，SPA的优势压倒性。别指望一套方案打天下。
落地即踩坑：三个让你怀疑人生的陷阱
陷阱一：SEO——搜索引擎说“我看不懂你的客户端渲染”
大部分爬虫不会执行JavaScript。你的SPA在它们眼里就是个空壳index.html，正文一片白。百度直到现在对SPA的抓取支持都不太行，谷歌好一些，但也会延迟索引。别听信“Google能渲染JS”就裸奔，渲染队列和资源限制会让你排在十页之后。
解决方案分三级。轻量方案：预渲染（prerender-spa-plugin），构建时生成静态HTML快照，适合博客、文档站，路由固定几十页那种。但数据依赖动态接口的页面就废了。重量方案：SSR，比如Nuxt.js、Next.js，服务端实时渲染出HTML。代价是服务器压力增大，需要处理Node进程崩溃、缓存策略，而且组件生命周期比客户端多一层，写代码时就得注意不能直接操作window。我们曾经搞了个折衷——无头浏览器动态渲染，用Puppeteer预渲染高频访问页面，每天定时跑一次。时效性新闻页就别这么玩了，用户会看到昨天的内容。
陷阱二：首屏白屏时间——用户等不起
前面提到SPA首屏慢，如果还按默认方式来，把UI库、图表库、工具类全打包进一个bundle，用户网速稍差就可能对着白屏10秒。我优化过的一个项目，初始bundle 2.7M，P90加载时间4.8秒，跳出率45%。
拆！路由懒加载是必须的，每个路由对应的组件切割成独立chunk，访问时才下载。然后静态资源上CDN，开启gzip甚至br压缩。第三方库能用tree shaking的全切小，moment.js换成day.js，lodash别整套引入。首屏关键CSS内联，非关键异步加载。最后用Skeleton屏或loading动画安抚用户。优化后bundle降到600KB，First Paint耗时1.1秒。虽然还是比MPA慢，但用户无感，跳出率降到12%。
陷阱三：内存泄漏——因为不刷新页面
传统MPA每次跳转相当于重启，JS环境重置，变量销毁。SPA里你永远不会完全重置。全局变量、事件监听器、定时器、闭包引用……都可能长期驻留。我遇到最坑的一次，在SPA的管理后台里，用户连续用了四五个小时后页面直接崩溃。
后来用Chrome DevTools的Memory面板抓heap snapshot，发现某个图表组件实例并没有被GC回收，因为它内部注册的document事件监听没有解绑。还有setInterval忘了clear，每秒都创建一个新对象。Vue/React的组件销毁时如果手动addEventListener了，必须在beforeDestroy/useEffect返回清理函数里remove。另外像WebSocket连接、Observer实例也要关闭。一个快速检测的方法：反复进出某页面10次以上，看memory曲线是否锯齿状上升。平稳才对。
治本靠工具和规范。我们后来强制要求每个组件在destroy生命周期里做cleanup review，并引入WeakMap解决某些缓存场景下的意外引用。线上还加了内存告警——超过阈值自动dump分析。
说到底，SPA不是万能药，甚至有时候是毒药。但理解它的里子，用好工具链，别什么都往“最佳实践”上靠，你才有资格说这就是最佳实践。
