谋划已久的蓄力：我的官网第三次重构（Nuxt3 + Naive UI + Nginx

Sun, 17 May 2026 07:22:34 +0000

最近，我使用 Nuxt3 全面重构了我的官网。大功告成后经实测发现，首屏加载速度其实变慢了。但奇妙的是，这次重构我却一点都不后悔。

上一个版本的官网，我是用最纯粹的 HTML+CSS+JS 开发的。说实话，刚写完的时候自己非常满意，纯原生代码，没有任何框架负担。但最近在规划我拥有的数字资产后续的功能时，我的想法发生了一些根本性的转变。我开始意识到，之前把很多工具一股脑塞进微信小程序里，其实并不合理。对于开发者或者需要高频使用不需要账号体系的工具的用户来说，在电脑大屏上操作，远比在手机上点来点去效率高得多，这也是我在小程序上实现没有多少人访问的原因吧。更别说每次改动功能就被小程序那让人头疼的、动不动就被卡住的审核机制了。于是我冒出一个强烈的念头：我要把小程序里适合在电脑上用的工具，全部搬到 Web 网页上来，面向全球用户开放；同时去精简小程序，让它只留下适合移动端且符合小程序场景的即开即用的功能。当我带着这个目标重新去审视我那套 HTML+CSS+JS 的旧代码时，我发现现在这样的写法后期维护起来极其麻烦。最让我抓狂的就是组件复用问题。在旧网站里，像导航栏和页脚这种每个页面都有的东西，要么靠人工全量复制粘贴，要么就直接缺失。每次我想改动一个导航菜单，就要把所有 HTML 文件全部手动改一遍。这种“原始人”一样的维护方式，对于我想规范化后期维护的人来说，不仅工作量巨大，而且写起来让人极度讨厌和烦躁。另一个更深层的坎是：我不希望这个官网仅仅是一个死板的展示页面。在我接下来的蓝图里，这个 Web 平台应该是一个“核心底座”——它能作为数据和逻辑的中心，向上能和小程序联通，向下能跟我的客户端工具做交互，而不是各自为战的孤岛。回看过去，这个官网前后重构了不下三次，但过去的改动大多只是 UI 层面的修修补补。而这一次，也许正是意识的苏醒，让我决定不再无谓地徘徊。为了彻底解决组件复用、多端联通以及降低未来维护成本的痛点，我最终敲定了 Nuxt3 + Naive UI + Nginx 这套架构，并决定长期坚持走下去。

跨端响应式的 UI 抉择，官网的 UI 必须完美兼容移动端、PC 端和平板端。以前尝试过很多 UI 框架，例如WeUI，Bootstrap等，都不尽如人意，我也不想再投入过多精力去试错。虽然我有丰富的后端管理平台 UI 开发经验，但总觉得那些框架不太适合做门户官网。我需要一款既简单易学、又能满足多端响应式需求的 UI 框架。刚好之前做客户端项目时用过 Naive UI，体验极佳，于是这次便果断选择了它。
确定使用 Naive UI 后，前端生态自然锁定了 Vue3。虽然原生 JavaScript 写简单页面很方便，但在实现复杂功能时，远不如 Vue3 高效。Vue3 内置了诸多便利功能，尤其是对有 Vue2 基础的我来说，上手极快。我非常享受在同一个 Vue 文件中把逻辑、页面、样式“一把刷”搞定的开发体验。
选定 UI 和前端底座后，我需要一个强大的开发框架来落地想法。这次重构，我计划编写一系列在线工具来替代微信小程序的部分功能，并计划停用小程序这些功能。经过改造后，我的这些工具将彻底面向全球用户开放，而不仅仅是小程序用户。在开发规范上，我更倾向于有组织、有约束的结构。经过一番调研，我发现当下流行的 Nuxt3 正好完美契合我的诉求。

为什么选择Nuxt3？

比如摆脱复制粘贴：以前使用原生开发网页，HTML 代码难以复用，缺乏组件化概念，每个页面都要复制粘贴相同的导航栏和底部，在没有框架的情况下，这些布局都需要每个页面去赋值。在 Nuxt3 中，我可以直接利用 Vue3 的 Layout（布局）机制完美解决。

状态管理与声明式渲染：纯 JS 操作 DOM 过于繁琐。对于习惯了后端逻辑的我来说，Vue3 的声明式渲染和响应式数据，写起来比纯单页面或原生 DOM 舒服太多，更符合我的思维习惯。

Nuxt3 on 豆子技术站

谋划已久的蓄力：我的官网第三次重构（Nuxt3 + Naive UI + Nginx

为什么选择Nuxt3？