nuxt3使用记录一：框架摸索

2024-04-17 17:01:15

之前直接用的Vue3，后面为了seo，了解到Vue3用SSR渲染很复杂，甚至衍生了出nuxt3这个框架，这个框架在github已经有50K star了，也已经是个非常成熟的框架了，不过我感觉国内的资料也不多，看来国内接受新事物的速度依然很慢，大厂估计都自研了，小公司就用老方法PHP啥的。

学习nuxt3最详细的资料也就是官方文档，不过，说实话也很不详细。我研究了几天，说难其实也不难，说简单也不简单，因为整个框架按约定的自动配置的东西非常多，不了解的话，不知道框架的运作机制，都不知道哪些文件该放哪里。
下面根据实践经验，记录一些觉得官方文档没详细介绍，又不那么好理解的东西

nuxt3 的SSR渲染原理

与Vue3传统渲染对比

Vue3的原始渲染，是单文件组件，渲染的结果是一个html加一个js和css文件等，服务器通过nginx等代理，让客户端可以获取到这个html文件（就跟获取个普通文件是一样的），浏览器访问html，从而再次加载js和其他静态文件，完全由客户端去解析js文件。所以服务器不需要nodeJS环境

优势劣势就不去对比了，网上很多，这里最大的问题是搜索引擎是不会爬取js里面的内容的，所以非常不利于seo。所以需要用到SSR渲染

SSR也就是能把Vue的页面，在服务器端就给渲染成静态的html页面，它是有网页的内容的，所以搜索引擎的爬虫能够直接获取到里面的内容，从而提高了seo，这里的服务器就需要有nodeJS环境去解析js文件从而渲染页面

nuxt3渲染机制（个人理解，可能有误）

但是这里有个问题，页面的有些数据是由后端动态提供的，所以在渲染页面前，需要先从后端获取数据。nuxt3解决该问题的办法，是在客户端和后端之间，还设置了一层server端：

客户端<——>server<——>后端

所以，在官方文档里，看到http请求方式大多是await的同步请求，和之前用axios的异步差异很大，以前都是要在.then()里面去处理后端的数据，否则客户端界面会卡死。而官方文档就描述的很不详细，其实它用await userfetch()向后端发起请求，那些场景都是在server端渲染页面时去做的，并不是客户端直接发起的请求，server把从后端获取的数据直接渲染成静态页面，再返回给客户端，客户端无需再次渲染，直接就展示页面。所以你看官方文档的代码老是await 。在真实业务上的客户端发起的http请求，还是要用promise进行异步请求。关于客户端的http请求，我也做了封装，感兴趣可以看看。

nuxt3框架一些不好理解的点

第三方组件引入

常见的就是引入UI组件，成熟的UI组件，应该都会适配NUXT3的，都会特别说明在NUXT3中如何引入，如何按需自动加载，自动导入等。如果没有官方适配的UI组件，建议换一个。
但是有时非用不可，也是可以的，就按照普通Vue3的引入方式，比如vite自动导入的（你说官方文档连vite的自动导入配置都没说明的，建议马上换一个），就在nuxt.config.ts的vite下进行配置：

import AutoImport from "unplugin-auto-import/vite";
import Components from "unplugin-vue-components/vite";
import { NaiveUiResolver } from "unplugin-vue-components/resolvers";
export default defineNuxtConfig({
	.........其他配置
	// 下面是我引入naiveUI 的配置
    vite: {
        plugins: [
            AutoImport({
                imports: [
                    {
                        "naive-ui": [],
                    },
                ],
            }),
            Components({
                resolvers: [NaiveUiResolver()],
            }),
        ],
    },
});

对，就照着原来的配置方法配置就好（除非官方有专门的nuxt配置说明），不过，有可能那些自动导入，按需导入的功能会失效。

路由

nuxt3的路由也是基于Vue-route封装的，所以从老项目迁移的时候，还能不换路由方式，但是它又做了封装，比如<router-view >就没用了，你得用<NuxtPage />来代替，关键它不如<router-view >*，在嵌套路由上，nuxt限制很多。

nuxt3使用文件路由，根目录下的pages目录下的所有.vue文件都会根据文件名和目录名自动生成路由。这样可以省略路由配置，但是却加了很多限制，特别是嵌套路由。

比如我的页面是由顶部导航栏+左侧导航栏+中间区域组成，之前我用个layout组件分区域，然后<router-view >来切换中间区域的内容即可。但是不能直接用<NuxtPage />来实现。你必须按照他的嵌套路由规则，来实现嵌套路由，才能实现上面的这种布局。

而nuxt3中，像这种布局需求，需要用到layout组件来实现，如果你只有一种布局，建议直接卸载app.vue 上，这里的内容全局应用，也就意味着顶部导航栏始终存在于所有页面中。至于多种布局的，我还没研究，建议看官方文档琢磨下。

总之，nuxt3的路由很死板。刚用很不习惯。不过倒是省了一些代码

路由中间件

路由中间件也有固定的实现模板，先在根目录新建文件夹middleware这个文件夹的，然后新建一个route.global.ts文件，带global后缀的文件，意味着它全局应用，所有路由都会调用。然后其中的方法：

export default defineNuxtRouteMiddleware((to, from) => {
    if (to.path === "/") {
        return navigateTo("/home/about");
    }
});

对，这个方法的名称也是固定的，这里的所有几乎都是固定的，也就是框架的约定，你只要这么写，他就会自动加载了。再复杂的中间件我也没去研究了。

状态管理（简单理解为全局变量）

nuxt3框架提供了自带的状态管理模块useState()，你可以在任何地方像下面这样定义一个全局变量：const counter = useState<number>('counter', () =>1)
不过我建议在composables目录下新建一个ts文件来定义和初始化这些全局变量，因为这样可以避免在初始化前被调用，并且目录里的全局变量也会自动加载，所有地方直接使用，无需手动导入：
例如我在composables目录下新建一个locale.ts文件:

export const useCounter = () => {
    return useState<number>("counter", () => 1);
};

然后，你就可以在其他.vue和 .ts文件中引用该全局变量（无需手动导入useCounter）：

let counter=useCounter().value

或者，你可以直接全局修改它的值：

useCounter().value++ // 任意地方进行全局修改

使用还是很简单的。所以，我放弃引入pinia了，因为我就是简简单单的定义一些全局变量，nuxt3自带的这个更好用。

静态项目构建

nuxt3默认生成的框架就自带了两种构建命令：

        "dev": "nuxt dev", // 开发环境直接运行
        "build": "nuxt build", // 混合渲染构建
        "generate": "nuxt generate", // 纯静态构建

nuxt3总体来说支持三种构建方式：

默认的混合渲染构建，对应的也就是SSR，不过它支持自定义配置，哪些页面静态构建，哪些还是走传统的SPA，我没深究，但是确实支持对每个页面的构建方式指定，对应的命令是：nuxt build
第二种是传统vue3的SPA构建，需要在nuxt.config.ts中配置ssr:false。这样就进行SPA构建，不过这种方式的话，建议直接使用vue3传统项目框架来整，然后执行nuxt build
第三种就是SSG构建，就是纯静态页面，这种构建最有利于seo，且无需server端渲染，是对客户端和服务端都最友好的方式，缺点就是页面是纯静态的，无法根据数据动态生成。对应的命令是：nuxt generate

我第一次构建挺顺利的，说明这个框架挺成熟的，就只遇到一个地方报错，我原先在pages目录下创建了个.ts文件，用来写一些通用的方法，这个文件在SSG构建时是不行的，也就是说pages目录下不允许有.ts文件。所以我就把这个文件挪到composables目录下去，就可以了。构建出来的页面也没啥问题，都挺好的。整体大小比SPA方式更小。

码农公寓