Nuxt typecheck 在 shared 上下文找不到 computed，检查 app.config 的类型引用

nuxt typecheck 报 Cannot find name 'computed' 或 Cannot find name 'useNuxtApp'，错误文件明明在 app/ 中，却是在检查 .nuxt/tsconfig.shared.json 时被带进来的，可以沿生成声明的导入链检查 app.config。

Nuxt 4.3.0 起已有 shared 类型上下文混入 app 源码的故障。其后仍有一条明确路径：供 shared、server 或 Node 配置使用的 types/app.config.d.ts 引入用户的 app.config 文件，再沿导入图进入依赖 app 自动导入的 composable。正式版 Nuxt 4.5.1 对这条配置声明路径作了隔离。

找到错误属于哪个 TypeScript program

不要只按错误文件位于 app/ 就认定 Vue 自动导入失效。Nuxt 把 app、server、shared 和配置代码放在不同类型环境中；同一源码若被另一个环境的导入图拉入，那个环境未必拥有 computed、useNuxtApp 等全局声明。

在已安装项目依赖的工作区中，可让现有类型检查工具显示项目引用顺序：

pnpm exec vue-tsc --build --noEmit --verbose

示例适用于原项目已经使用 pnpm 和 vue-tsc 的情况，不要求另装一份检查器。保留原来的检查入口与锁文件，观察诊断出现在 shared、server 还是 app program，并查看它引用的 .nuxt/types/ 声明。

若导入链没有经过 app 配置声明，继续检查实际的层、模块或共享代码导入。这里只处理已确认的上下文越界路径，不能把所有自动导入错误都归给 app.config。

4.5.1 的隔离也改变了外部可推断范围

已核对的 Nuxt 4.5.1 为 app 以外的类型环境使用 shared-app.config.d.ts。它不再导入用户 app.config 的源码，因此不会为了推断配置形状而把整条 app 导入链拉进来。

完整的 app.config 自动推断仍供 app 代码使用。在 server、shared 和 nuxt.config 中，仅由 app.config 文件定义的键可能变成 unknown；写在 nuxt.config 的内联 appConfig 中的键，以及适当作用域内的显式配置类型扩充，则有各自的类型来源。

因此，更新后看见某个配置键不再被完整推断，不一定是另一个回归。若共享代码确实需要它的契约，应为对应配置接口声明需要的类型，并把声明放在需要可见的上下文里，而不是重新导入 app 的 composable 来找回推断。

更新实际 Nuxt 依赖后，通过原项目流程重新准备生成类型，再检查 .nuxt 中的引用。不要直接编辑生成的 tsconfig 或 .d.ts；下次准备或安装会把手工修正覆盖。

临时删除根 tsconfig 中的 shared 项目引用，可能让眼前错误消失，但也会丢掉共享代码的检查。把 server-only 全局统一注入 app，或把 app 全局注入所有环境，同样会掩盖真实的运行环境错误，不宜当作长期方案。

重新运行完整类型检查，确认原错误消失，同时验证 app、server 和 shared 仍分别接受预期声明、拒绝不该使用的 API。再运行原有构建；类型诊断消失本身不能证明服务端没有误用浏览器能力。