SolidStart SSR 渲染中 Cookie 传递问题的分析与解决方案

在 SolidStart 项目中使用服务器端渲染(SSR)时，开发者可能会遇到一个常见但容易被忽视的问题：在 SSR 阶段发起的 API 请求中，Cookie 头信息未能正确传递。本文将深入分析这一问题，并提供切实可行的解决方案。

问题现象

当我们在 SolidStart 应用中实现 SSR 时，如果在页面组件中使用 fetch 发起 API 请求，会发现一个有趣的现象：

1. 在服务器端渲染阶段发起的请求中，Cookie 头信息丢失
2. 但在客户端发起的相同请求中，Cookie 头信息却能正常传递

这种差异会导致 SSR 阶段无法获取到用户的认证信息，进而可能影响页面内容的正确渲染。

问题根源

经过分析，我们发现问题的本质在于：

1. SSR 阶段的 fetch 调用与浏览器环境的 fetch 行为不同
2. 默认情况下，SSR 中的 fetch 不会自动携带原始请求的头部信息
3. 虽然入口文件(entry-server.tsx)能获取到完整的请求头，但这些信息不会自动传播到组件树的 fetch 调用中

解决方案

SolidStart 提供了 getRequestEvent 工具函数，可以让我们在组件中访问当前的请求上下文。利用这个特性，我们可以手动将请求头传递给 fetch：

import { getRequestEvent } from 'solid-js/web';

const [res] = createResource(() => {
  const event = getRequestEvent();
  return fetch("/api/test", { 
    headers: event?.request.headers 
  }).then(res => res.json());
});

这种方法确保了 SSR 阶段的 API 调用能够携带与原始请求相同的头部信息，包括 Cookie。

最佳实践建议

1. 封装通用请求函数：建议将这种带请求头的 fetch 逻辑封装成项目通用的请求函数，避免重复代码。

2. 注意请求头安全性：只传递必要的请求头，避免泄露敏感信息。

3. 考虑环境差异：在客户端和服务器端使用不同的请求逻辑时，确保行为一致性。

4. 错误处理：添加适当的错误处理逻辑，特别是当 getRequestEvent 返回 undefined 时。

总结

SolidStart 的 SSR 机制提供了强大的功能，但也需要开发者理解其内部工作原理。通过正确使用 getRequestEvent 和手动传递请求头，我们可以解决 SSR 阶段 Cookie 丢失的问题，确保应用在各种环境下都能正常工作。

理解这些底层机制不仅能帮助我们解决当前问题，还能为处理更复杂的 SSR 场景打下坚实基础。