SvelteKit+Playwright e2e测试中如何Mock后端第三方服务调用

先明确核心踩坑点：Playwright原生的page.route()只能拦截浏览器客户端发起的网络请求，SvelteKit的服务端逻辑（包括hooks.server.js/共享hooks.js里的服务端逻辑、服务端load函数、+server.js接口中触发的外发请求，比如第三方登录跳转、AWS S3调用）是运行在Node/Edge服务端runtime中的，完全不经过浏览器网络栈，所以原生路由拦截根本触达不了这类请求，直接用下面三类方案即可，覆盖你提到的hooks鉴权重定向、S3调用全场景：

方案1：环境变量驱动的可注入适配层（首推，复用性最高） #

这套方案改造成本低，后续新增任何第三方依赖（支付、短信、其他OpenAPI）都能直接复用，不需要反复调整测试配置：

• 第一步先做依赖抽离，不要在hooks、业务逻辑里直接硬编码第三方请求地址、SDK调用逻辑。把所有外发的第三方调用统一收敛到src/lib/server/third-party/目录下的独立模块，比如单独写auth.js处理第三方登录逻辑、s3.js封装所有S3的上传下载方法。
• 第二步在Playwright配置里给SvelteKit启动进程注入测试环境标记，示例配置：

// playwright.config.js
import { defineConfig } from '@playwright/test'

export default defineConfig({
  webServer: {
    command: 'npm run dev',
    url: 'http://localhost:5173',
    reuseExistingServer: !process.env.CI,
    env: {
      MOCK_THIRD_PARTY: 'true' // 自定义Mock开关
    }
  },
  testDir: './tests',
  // 其余常规测试配置
})

• 第三步在封装的第三方模块里做环境分支，测试环境自动切换为Mock实现。比如你hooks里用到的第三方登录跳转逻辑：

// src/lib/server/third-party/auth.js
export const getThirdPartyLoginUrl = (targetPath) => {
  if (process.env.MOCK_THIRD_PARTY === 'true') {
    // 测试环境直接返回本地Mock登录路由，完全不触达外网
    return `/mock-login?redirect=${encodeURIComponent(targetPath)}`
  }
  // 非测试环境走真实第三方登录地址
  return `https://{真实第三方鉴权服务域名}/login?redirect=${encodeURIComponent(targetPath)}`
}

S3的调用逻辑处理方式完全一致，Mock实现里直接返回预设的文件内容、上传成功响应、固定文件URL即可，不需要真实连接AWS服务。如果不同测试用例需要不同的Mock返回值，只需要在测试发起请求时加自定义请求头，服务端从event.request.headers里读取标记动态返回对应结果即可，不需要重启服务。

方案2：服务端全局网络拦截（适合不想重构业务代码的场景） #

如果现有项目已经把第三方调用散落在各个逻辑里，暂时不想做抽离，可以直接用服务端层面的网络拦截工具，在SvelteKit服务启动前挂载拦截规则：

• 工具选支持对应runtime的拦截库即可：如果用SvelteKit Node适配器，选nock或者MSW的Node拦截模式；如果跑Edge runtime，直接用MSW的Edge适配版本，不要用依赖Node原生http模块的库。
• 在Playwright的globalSetup生命周期里初始化拦截规则，匹配所有需要Mock的第三方域名：比如第三方登录服务域名、S3的API域名，直接返回预设响应或者重定向规则。
• 这类拦截是在服务端runtime层面劫持网络请求，不管是hooks里触发的跳转、还是AWS SDK发出的S3请求，只要是SvelteKit服务端发出的，都会被拦截，不会真实向外发送。

方案3：本地反向代理映射（零业务侵入，配置成本稍高） #

如果项目已经上线，完全不方便改动业务代码，可以在测试启动时额外起一个本地极简代理服务：

• 把所有用到的第三方服务域名，通过环境变量配置替换为本地代理地址，或者在启动SvelteKit服务时加本地域名映射规则
• 在代理服务里配置路径匹配规则：匹配到登录路径就返回本地登录页重定向，匹配到S3 API路径就返回预设的存储响应
• 这套方案完全不需要改动业务代码，但是需要额外维护代理的路由规则，适合重构成本极高的存量项目。

实践提示：不要浪费时间尝试用page.route()拦截服务端请求，二者不在同一个网络链路里，根本无法生效。优先选第一套适配层方案，本质是做依赖倒置，后续新增任何第三方服务都只需要在适配层加Mock实现，测试逻辑和业务逻辑完全解耦，长期维护成本最低。针对你提到的hooks重定向场景，用第一套方案时还可以在本地加个/mock-login对应的路由，模拟第三方服务登录成功后写用户session、跳回目标页的逻辑，整个鉴权流程可以完全闭环覆盖。

内容的提问来源于stack exchange，提问作者Kyle L.