在SvelteKit中突破布局实现页面权限控制的方案探讨

我正在开发一个SvelteKit应用，需要区分受会话Cookie保护的页面和公开访问页面：

• /（首页）：需验证会话Cookie，未验证则重定向至/login
• /invoices：需验证会话Cookie，未验证则重定向至/login
• /login：公开访问
• /signup：公开访问

以下是现有方案、遗漏方案的梳理，以及选型建议：

现有方案一：路由组拆分（(app) 与 (public)） #

目录结构：

src/routes/
│ (app)/
│ ├ +layout.server.ts // 校验会话Cookie，未通过则重定向到/login
│ ├ +page.svelte   // 首页
│ ├ invoices/
│ │ ├ +page.svelte  // /invoices页面
│ (public)/
│ ├ +layout.svelte  // 公开页面布局，不做Cookie校验
│ ├ login/
│ │ ├ +page.svelte  // /login页面
│ ├ signup/
│ │ ├ +page.svelte  // /signup页面
└ +layout.svelte    // 所有页面共享的根布局

核心逻辑：用路由组将受保护页面和公开页面物理隔离，受保护组的+layout.server.ts统一处理校验逻辑，公开组直接跳过校验。

现有方案二：根布局全局校验，排除公开路径 #

目录结构：

src/routes/
├ +layout.server.ts // 默认校验会话Cookie，仅当路径为/login或/signup时跳过
├ +page.svelte   // 首页
├ invoices/
│ ├ +page.svelte  // /invoices页面
├ login/
│ ├ +page.svelte  // /login页面
├ signup/
│ ├ +page.svelte  // /signup页面

核心逻辑：在根布局的服务端代码中维护公开路径列表，默认所有页面受保护，匹配到公开路径时跳过校验。

遗漏的方案：页面级单独标记控制 #

子方案1：受保护页面单独添加校验逻辑 #

在每个需要保护的页面的+page.server.ts中重复写入会话校验：

// src/routes/+page.server.ts
export async function load({ cookies, redirect }) {
  const session = cookies.get('session');
  if (!session) {
    throw redirect(303, '/login');
  }
  // 页面业务逻辑
}

// src/routes/invoices/+page.server.ts
export async function load({ cookies, redirect }) {
  const session = cookies.get('session');
  if (!session) {
    throw redirect(303, '/login');
  }
  // 发票页面业务逻辑
}

公开页面不添加任何校验逻辑即可直接访问。

子方案2：路由元数据统一控制 #

通过路由元数据标记页面是否需要保护，再在根布局中统一处理：

1. 给受保护页面添加元数据：

// src/routes/+page.server.ts
export const metadata = {
  requiresAuth: true
};

// 页面业务逻辑...

// src/routes/invoices/+page.server.ts
export const metadata = {
  requiresAuth: true
};

// 页面业务逻辑...

2. 根布局中读取元数据并校验：

// src/routes/+layout.server.ts
export async function load({ route, cookies, redirect }) {
  const requiresAuth = route.metadata?.requiresAuth ?? false;
  if (requiresAuth) {
    const session = cookies.get('session');
    if (!session) {
      throw redirect(303, '/login');
    }
  }
}

方案选型：推荐路由组拆分（方案一） #

这是最贴合SvelteKit路由设计哲学的方案，优势明显：

• 职责清晰：受保护页面和公开页面物理隔离，校验逻辑集中维护，无需手动管理路径列表，避免遗漏或误操作。
• 扩展性强：新增受保护页面直接放进(app)组，新增公开页面放进(public)组，无需修改现有校验逻辑。
• 布局灵活：不同路由组可以使用差异化布局（比如受保护页面带侧边栏，公开页面用极简布局），同时共享根布局的公共元素（如页脚）。

对比其他方案：

• 方案二需要手动维护公开路径列表，页面增多后逻辑会臃肿，容易出错。
• 页面级单独标记方案要么重复代码多（子方案1），要么依赖元数据容易遗漏配置（子方案2），维护成本更高。

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