openapi-typescript 项目中关于相对路径和代理URL访问问题的解析

问题背景

在使用openapi-typescript项目中的openapi-fetch库时，开发者遇到了一个关于URL处理的常见问题。当通过前端代理配置访问后端API时，使用常规fetch能够正常工作，但使用openapi-fetch时却出现了ERR_INVALID_URL错误。

问题现象

开发者配置了前端的代理设置，将前端请求的/api路径重定向到后端服务。正常情况下，请求路径应该被重写为后端服务的实际URL。然而，当使用openapi-fetch时，请求仍然保留了原始路径/api/...，导致URL无效错误。

技术分析

根本原因

openapi-fetch库在默认情况下使用globalThis.fetch，并且对URL的处理方式与常规fetch有所不同。它内部使用了createFinalURL和defaultPathSerializer函数来构造最终请求URL，这可能导致代理重写规则被绕过。

解决方案验证

开发者尝试了多种解决方案：

1. 直接传递自定义fetch函数（如SvelteKit提供的fetch）
2. 在单个请求中指定fetch参数
3. 在创建客户端时设置baseUrl参数

最终发现，只有设置baseUrl参数才能解决问题。这表明openapi-fetch在URL处理上需要明确的基准URL才能正确工作。

最佳实践建议

对于使用前端框架（如SvelteKit）并需要代理API请求的开发者，建议采用以下配置方式：

const apiClient = createClient({
  fetch: customFetchFunction,  // 使用框架提供的fetch
  baseUrl: window.location.origin  // 明确设置基准URL
})

这种配置确保了：

1. 使用了正确的fetch实现（可能包含框架特定的增强功能）
2. URL构造基于正确的基础路径
3. 与代理配置兼容

技术原理深入

openapi-fetch的这种行为设计是为了确保API请求的可预测性。在复杂的现代前端开发环境中，特别是在使用服务端渲染和代理配置时，明确指定baseUrl可以避免因环境差异导致的URL解析问题。

总结

在使用openapi-fetch时，特别是在代理API请求或服务端渲染场景下，明确设置baseUrl参数是确保URL正确处理的关键。这不仅是解决当前问题的方案，也是一种良好的实践，可以使API客户端的行为更加可预测和可靠。