https://niuzj.org/tags/vite/ Recent content in Vite on niuzj Hugo zh-cn Mon, 13 Jul 2026 00:00:00 +0800 https://niuzj.org/posts/lumen-hybrid-ssr-spa-navigation-performance/ Mon, 13 Jul 2026 00:00:00 +0800 https://niuzj.org/posts/lumen-hybrid-ssr-spa-navigation-performance/ <p>最近在做自己的项目 <a href="https://lumenstudio.tech/">Lumen</a>。随着工作台功能逐渐变重，前端导航在开发后期明显慢了下来。最初让我不舒服的不是某个接口慢，而是一个很具体的现象：Dashboard、项目、素材和热门视频明明属于同一个工作台，来回切换时却仍然像在重新进入一个页面。</p> <p>顶栏会重走导航，页面边界重新建立，业务数据再发请求。对于一个用户会连续使用很久的创作工具，这种等待会在一天里重复很多次。单独优化某个 Mongo 查询，解决不了这件事。</p> <p>我一开始也把原因粗略归结为“SSR 每次切页都要重新渲染”。这个说法并不严谨。Next.js App Router 的客户端导航不等于浏览器整页刷新，也不是每次都重新 hydration；它可以预取并复用客户端状态。但应用区的路由仍然属于 Next.js 运行时，未命中的路由段和 RSC 数据可能需要再次经过服务端边界。</p> <p>真正需要拆开的，是两件原本绑在一起的事：<strong>切到哪个页面</strong>，以及<strong>这个页面要读取什么业务数据</strong>。</p> <h2 id="卡顿不在一个接口而在路由所有权">卡顿不在一个接口，而在路由所有权</h2> <p>Lumen 原来只有 <code>lumen-studio</code>。落地页、登录、注册、工作台和面向浏览器的同源 <code>/api/*</code> 都在同一个 Next.js 项目里。</p> <p>这对门面页面很合适。陌生用户第一次进入，需要服务端生成内容、处理语言和登录跳转，也可能关心搜索引擎抓取。但登录后的应用区不是这种访问模式。用户会在 <code>/dashboard</code>、<code>/canvas/projects</code>、<code>/materials</code> 和 Canvas 之间连续操作，页面结构稳定，变化的主要是客户端状态和 API 数据。</p> <p>如果继续让 Next.js 持有这些路由，每次导航都可能穿过服务端路由协议。即使页面组件本身已经是 Client Component，路由边界仍然没有离开 Next.js。</p> <p>这次改造的判断不是“SSR 慢，SPA 快”，而是：</p> <blockquote> <p>门面页需要服务端参与首屏，应用区更需要一个长期存活的客户端运行时。</p> </blockquote> <p>于是 Lumen 没有把整个站改成 SPA，而是把 <code>/app</code> 下的页面路由所有权交给浏览器；<code>/app/api/*</code> 仍然是服务端接口。</p> <h2 id="两个-commit-切出了第二个运行时">两个 commit 切出了第二个运行时</h2> <p>这次变化主要落在两个 commit 上。</p> <p><code>6224269 perf(studio): split app shell</code> 建立了新的 <code>apps/lumen-app</code>：Vite 负责打包，React 负责渲染，TanStack Router 负责 <code>/app/*</code> 页面路由。与此同时，Dashboard、Materials、Canvas 等旧 Next.js 页面被改成跳转到新的 SPA 地址。</p>