先确认现象

升级 Nuxt 3 的 Pinia 服务端状态初始化配置，通常是从旧版（Nuxt 3.5 及以下）跳到 3.6+ 时遇到的问题。我会先检查当前项目的 Nuxt 和 Pinia 版本。素材1原样说：升级前先检查当前项目的 Nuxt 版本和 Pinia 版本。如果使用 Nuxt 3.6 以下的版本，Pinia 需要手动安装并配置 plugin；而 Nuxt 3.6+ 内置了 @pinia/nuxt 模块，但初始化配置方式有变动。查看 package.json 中 nuxt 和 pinia 的版本号，若 nuxt >= 3.6 且 pinia >= 2.1.0，则可采用新的 usePinia() 函数代替旧的 defineStore 方式。这一步很关键，因为版本不对直接决定后续步骤。

如果发现项目还在用旧版插件方式（比如 plugins/pinia.ts 里写 import { defineStore } 并手动注入 $pinia），而 nuxt 版本已是 3.6+，那就说明需要迁移。不要直接复制旧代码，否则服务端渲染时 state 可能为空。

建议的处理顺序

素材6给出了一个稳妥的迁移顺序。原文如下：建议按顺序执行：首先，更新 package.json 中的 pinia 依赖至 ^2.1.0 以上，并确认 nuxt 版本 >= 3.6。其次，删除旧版的 plugins/pinia.ts 文件（如果有自定义初始化逻辑）。然后，将 store 中的 defineStore 重构，确保 state 函数不依赖于客户端特有的 API（如 window、localStorage）。最后，在需要服务端初始化的页面或组件中，使用 'const store = useStore()' 并在 'onBeforeMount' 或 'useAsyncData' 中判断 'process.server' 来仅填充一次数据。

这个顺序可以避免常见冲突。例如，如果先删除 plugin 而不更新 store，可能会导致找不到 $pinia 报错。建议先更新依赖、再删除旧文件、再重构 store，最后调整页面调用。每一步做完都可以跑一次 build 来确认没有语法错误。

配置调整示例

素材2提供了具体的配置调整思路。原文如下：在 nuxt.config.ts 中，如果之前通过 modules 注册了 @pinia/nuxt，且使用了 'pinia:init' hook 进行服务端状态初始化，升级后需要改用 runtimeConfig 或 import.meta.server 判断。具体操作：移除 modules 中的 pinia 条目，改为在顶层添加 'modules: ["@pinia/nuxt"]'（若未添加），然后在 store 中通过 defineStore 的 id 和 state 函数定义初始值，利用服务器端渲染时的 setup 函数预先填充 state。

举个例子，如果旧版 nuxt.config.ts 里 modules 写的是 'modules: ["@pinia/nuxt"]' 但后面又用 pinia:init hook，升级后可以直接去掉 hook，在 store 的 state 中用 async 函数填充。但注意：state 函数不能是异步，所以数据的填充应放在 action 里，然后在 server 端调用 action。具体实现可以用 nuxtServerInit 或 useAsyncData 配合 store 的 action。

验证方法

素材3给出了验证的核心操作。原文如下：升级后务必进行服务端渲染效果验证：在本地运行 'npm run build && npm run preview'，然后打开浏览器开发者工具，查看网络请求中的 HTML 响应内容。重点检查 Pinia 对应的 state 是否已内联在