Nuxt 3单项目如何承载多域名站点并实现页面隔离与资源复用？

完全可以基于单个Nuxt 3项目实现多独立域名站点承载，满足页面资源隔离、公共代码复用的需求。Nuxt 3底层的Nitro服务引擎、路由系统、分层架构能力原生支持这类多站点场景，不需要拆分多个独立代码仓库。

方案1：域名映射 + 路由分层（轻量场景首选） #

这个方案改造成本最低，适合站点数量在5个以内、页面结构差异不大的场景，实现逻辑很直接：

• 先在项目内维护统一的站点配置映射表，把每个域名对应的站点ID、页面目录、静态资源路径、功能开关、SEO配置全部统一维护：

// config/sites.ts
export const siteMap = {
  'websitea.com': {
    id: 'a',
    pageRoot: 'pages/site-a',
    assetRoot: '/static/a',
    siteTitle: '站点A',
    enableVipModule: true
  },
  'websiteb.com': {
    id: 'b',
    pageRoot: 'pages/site-b',
    assetRoot: '/static/b',
    siteTitle: '站点B',
    enableVipModule: false
  },
  'websitec.com': {
    id: 'c',
    pageRoot: 'pages/site-c',
    assetRoot: '/static/c',
    siteTitle: '站点C',
    enableVipModule: true
  }
} as const

• 写一个全局服务端中间件，请求进来时读取event.node.req.headers.host匹配对应站点配置，挂载到事件上下文，再通过useState把站点信息同步到客户端，封装一个useCurrentSite()的composable供全项目调用。
• 页面隔离直接按目录拆分：不同站点的页面放到各自独立的pages子目录下，加全局路由守卫做拦截，比如访问websitea.com时只允许匹配site-a目录下的路由，其他路径直接返回404，从访问层切断跨站点页面的访问路径。静态资源也按站点分目录存放，渲染时只加载当前站点对应目录下的资源。
• 公共的components、composables、utils直接放在Nuxt默认的对应目录下，所有站点可以直接复用，不需要额外处理。

方案2：Nuxt Layers 分层架构（中大型场景首选） #

如果各站点功能、页面差异较大，后续还要持续新增站点，直接用Nuxt原生的Layers能力做架构隔离，是官方推荐的长期维护方案：

• 项目根目录只保留公共层代码：通用组件、共享composables、工具函数、全局配置（比如请求封装、权限逻辑、全局样式），作为所有站点的基础依赖。
• 在项目内新建layers/site-a、layers/site-b、layers/site-c这类独立层目录，每个层内部就是完整的Nuxt子项目结构，有自己独立的pages、static、store，甚至专属的组件、逻辑，不同层之间的代码天然隔离，不会互相引用。
• 在nuxt.config.ts里根据当前请求的域名动态加载对应站点层，核心配置参考：

// nuxt.config.ts
const currentDomain = process.env.NUXT_PUBLIC_CURRENT_DOMAIN
export default defineNuxtConfig({
  // 全局公共配置统一写在这里
  extends: [
    currentDomain === 'websitea.com' ? './layers/site-a' :
    currentDomain === 'websiteb.com' ? './layers/site-b' : './layers/site-c'
  ]
})

• 部署时既可以配合CI流程，构建时传入不同的域名环境变量，打出每个站点独立的构建产物；也可以在运行时动态匹配加载对应层。这个方案的隔离性远好于第一种，各站点的专属代码不会进入其他站点的构建包，产物体积更优。

方案3：Nitro 多入口构建（极致性能/稳定性场景） #

如果对站点隔离性、响应性能要求最高，不想在运行时做多余的域名判断逻辑，可以直接用Nitro的多入口能力实现：

• 保留根目录公共代码的同时，把每个站点的独立页面、资源放到专属目录下。
• 在Nitro配置里定义多入口规则，每个入口绑定对应域名，构建时Nitro会自动把公共代码抽成共享chunk，每个站点的独立代码单独打包。线上请求进来时直接路由到对应入口处理，完全没有运行时的路由判断开销。
• 这个方案的构建产物天然隔离，单个站点的代码故障不会影响其他站点运行，适合对SLA要求很高的多站点运维场景。

• 客户端存储（Cookie、LocalStorage、SessionStorage）要做隔离，写存储key时带上当前站点的唯一标识，避免同部署环境下多域名的存储串读。
• SEO相关的meta信息、sitemap、robots.txt必须根据当前请求域名动态返回，不要写死全局统一配置。
• 如果用SSG模式部署，构建时遍历所有站点配置，分别生成每个域名对应的静态资源目录，部署时把不同域名的根路径指向对应生成目录即可。

内容的提问来源于stack exchange，提问作者Keith Petrillo