SvelteKit中handleFetch的event.route.id显示来源路由而非请求端点问题咨询

这是SvelteKit的设计逻辑，不是bug，三个钩子的event上下文定位本来就存在差异：

差异原因 #

• handle()：负责拦截外部进入服务器的请求（比如用户直接访问/api/users/123，或前端路由跳转过来的请求），event对应目标端点的路由上下文，因此能拿到api/users/[id]。
• handleFetch()：负责拦截服务器内部发起的fetch调用（比如你在admin/users/123的+page.server.js里调用fetch），这里的event是发起fetch的路由的上下文——因为fetch是在admin/users/123的load函数里执行的，所以它携带的是发起方的route.id。
• handleError()：只有当错误在目标端点的处理逻辑中抛出时，event才对应目标路由；如果错误来自发起方（比如admin/users/123的load函数），event就会变成发起方的路由。你这里的错误应该是在api端点里抛出的，所以拿到了api/users/[id]。

如何在handleFetch中获取目标端点的route.id？ #

如果需要拿到fetch目标的route.id，可以手动解析目标URL，再用SvelteKit的路由匹配工具找到对应路由：

import type { HandleFetch } from '@sveltejs/kit';
import { resolveRoute, matchRoute } from '@sveltejs/kit';

export const handleFetch: HandleFetch = async ({ event, request, fetch }) => {
  // 解析fetch目标的路径
  const targetUrl = new URL(request.url);
  const targetPath = targetUrl.pathname;

  // 获取服务器路由表并匹配目标路径
  const routes = await resolveRoute(event);
  const matchedRoute = matchRoute(routes, targetPath);

  if (matchedRoute) {
    console.log('目标端点的route.id:', matchedRoute.route.id); // 输出api/users/[id]
  }

  // 继续执行原fetch请求
  return fetch(request);
};

注意：resolveRoute和matchRoute是SvelteKit的内部API，虽稳定性较好，但版本更新时需留意官方文档的调整说明。

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