𝑾𝑱𝑼𝑵

Vue项目迁移Next日志

技术相关2420 字13 阅读0

最近正在优化我的博客项目，想好好摆弄一下服务端渲染和SEO优化等。多方研究下最终拍板决定使用Next.js重构我的Vue博客。

一开始我以为会很简单，但实际操作下来仿佛发现了新世界。

从代码架构到部署流程，完全是另外的一套体系。尤其是部署方式，不再是我熟悉的那种“前端打包 -> 上传 dist -> Nginx 托管静态文件”流程。

现在，我将带大家回顾一下我的项目迁移过程。记录一下 Next 项目与 Vue 项目的不同之处，以及一些我对 Next 的浅显理解。或许能对大家的技术栈转型起到一定帮助。

选择 Next.js 的原因

一是 Vue 风格的代码写多了，想试试其他口味。

二是听说 Next 对博客这种内容型网站的支持会更好，对 Google 的收录也有帮助。

三是 Next 天然支持服务器渲染，能够做到开箱即用。

实际体验下来，先不说在其他类型项目上的差异，就单独针对博客来说，我个人认为 Next 带给读者的体验是会比 Vue 更好的。

尤其是在：

  • 页面首次打开速度
  • SEO
  • 页面切换流畅度
  • 内容预渲染

这些方面，Next 的优势会比较明显。

代码架构的不同

路由

Vue 项目中通常需要使用 router 文件来统一定义路由。

而 Next 则是“目录即路由”。

例如：

app/page.tsx        -> /
app/about/page.tsx -> /about
app/blog/[id]/page.tsx -> /blog/:id

刚开始会觉得有些奇怪，但适应之后会发现这种方式非常适合博客这种页面结构清晰的网站。

全局状态管理

Vue 中常使用 Pinia。

而在 Next / React 生态中，常见方案则是：

  • Zustand
  • Redux
  • Context

不过实际开发博客时，我发现很多页面其实根本不需要全局状态。

因为 Next 更鼓励：

服务端获取数据 -> 直接渲染页面

很多以前放在 Pinia 里的内容，在 Next 中可能直接 fetch 一下就结束了。

接口调用

Vue 项目中一般会封装 axios。

而 Next 官方则更推荐直接使用 fetch。

比如：

const res = await fetch("https://api.xxx.com")

并且 Next 对 fetch 做了很多增强：

  • 缓存
  • 服务端请求
  • ISR
  • revalidate

这些都是 Vue 普通 SPA 中较少接触到的概念。

渲染方式

这是我觉得变化最大的地方。

Vue 普通项目通常是 CSR（客户端渲染）：

浏览器下载 JS -> 执行 JS -> 渲染页面

而 Next 则支持：

  • SSR（服务端渲染）
  • SSG（静态生成）
  • ISR（增量静态更新）

也就是说：

HTML 可以直接在服务器生成

浏览器打开页面时，很多内容其实已经存在于 HTML 中了。

这也是 Next 更利于 SEO 的重要原因。

use client

刚接触 Next 时，我经常遇到：

window is not defined
document is not defined

原因是：

Next 默认组件运行在服务器。

而：

  • window
  • document
  • localStorage

这些对象只存在于浏览器。

因此如果组件需要使用浏览器 API，需要在文件顶部加：

"use client"

让组件变成客户端组件。

部署方式的差异

这是我迁移过程中感受最深的一部分。

Vue 项目的部署

以前 Vue 的部署逻辑非常简单：

npm run build

得到：

dist/

然后：

上传 dist -> Nginx 托管

整个网站本质就是：

静态文件

Next 项目的部署

而 Next 完全不同。

因为 Next 存在：

  • 服务端渲染
  • Node 服务
  • 服务端组件

所以它并不是一个纯静态网站。

它需要：

Node.js runtime

也就是说：

Next 项目本质上是一个 Node 服务。

Docker 化部署

最终我选择了：

GitHub Actions + Docker + Nginx

这套方案。

整体流程大概是：

push代码
↓
GitHub Actions 自动执行
↓
SSH连接服务器
↓
git pull 拉最新代码
↓
docker build 构建镜像
↓
docker compose 重启容器
↓
Nginx反向代理

第一次接触时会觉得：

前端项目为什么突然这么“后端化”了？

但理解 SSR 之后就会发现：

Next 已经不只是传统意义上的“前端框架”了。

Docker 部署后的变化

以前 Vue 项目：

代码 = 网站

而现在：

镜像 = 网站

node_modules 不再存在于服务器目录中，而是被打包进 Docker 镜像内部。

这其实也是现代部署中非常主流的方案。

Next 使用体验

优点

SEO 确实更舒服

这一点是最明显的。

Vue SPA 虽然也能做 SEO，但通常需要：

  • SSR
  • 预渲染
  • 额外插件

而 Next 基本属于开箱即用。

App Router 很适合博客

比如：

/blog/[id]

这种结构非常自然。

文章、分类、标签页都很好组织。

服务端获取数据很舒服

以前 Vue：

页面加载 -> axios请求 -> 渲染

现在：

服务端 fetch -> 直接返回完整HTML

很多页面首次打开速度明显更快。

缺点

心智负担更重

相比 Vue：

会组件就能写页面

Next 需要理解很多新概念：

  • SSR
  • Hydration
  • Server Component
  • Client Component
  • Streaming
  • Cache

刚开始会比较绕。

部署复杂度提升

以前：

dist + nginx

现在：

Docker
Node
Nginx
CI/CD
反向代理

明显更加工程化。

容易前后端边界模糊

很多时候会产生一种：

我到底是在写前端还是后端？

的感觉。

博客方面的设计和优化

目前博客正在逐步完善中。

接下来准备优化的方向包括：

  • Markdown / MDX 渲染
  • 代码高亮
  • 目录导航
  • RSS
  • sitemap
  • 评论系统
  • 阅读量统计
  • SEO metadata
  • Open Graph 分享卡片
  • 暗黑模式
  • 页面过渡动画

开发技巧

Tailwind CSS

Tailwind CSS 极大提升了开发效率。

以前我其实不太喜欢这种“class 堆满页面”的写法。

但真正深入使用之后发现：

对于组件化开发来说，它的体验确实很好。

尤其是：

  • 快速搭布局
  • 响应式
  • hover 状态
  • 动画
  • 深色模式

非常舒服。

Docker 真的是现代前端绕不开的东西

以前总觉得 Docker 是后端才需要研究的东西。

但在真正接触：

  • Next.js
  • SSR
  • CI/CD
  • 自动部署

之后会发现：

现代前端其实已经越来越偏工程化。

最后

这次从 Vue 迁移到 Next，并不是简单的“换个框架”。

更像是：

从传统前端开发
进入现代全栈工程体系

虽然过程中踩了很多坑：

  • SSR
  • Docker
  • Nginx
  • GitHub Actions
  • 反向代理
  • Node 环境

但也因此接触到了很多以前不会关注的内容。

目前博客还在持续完善中，后续应该还会继续记录一些：

  • Next 开发经验
  • Docker 部署
  • 博客优化
  • SEO
  • 服务端渲染

相关内容。

评论

发表评论