SolidJS中createResource的SSR水合问题解析

问题现象

在SolidJS项目中，当使用createResource配合Show组件进行异步数据加载时，开发者可能会遇到一个奇怪的水合(Hydration)不匹配问题。具体表现为：

1. 首次服务器渲染(SSR)时显示正常
2. 客户端水合阶段出现"Hydration Mismatch"错误
3. 点击重置错误按钮后问题消失
4. 刷新页面后问题重现

错误信息通常为："Hydration Mismatch. Unable to find DOM nodes for hydration key: 0-0-0-0-0-0-0-3"

问题根源

这个问题的本质在于SolidJS的SSR渲染机制与客户端水合过程的不一致性。具体原因如下：

1. 服务器渲染行为：

   • 服务器首次渲染时，createResource尚未完成数据加载
   • Show组件检测到data.state !== 'ready'，渲染fallback内容
   • 服务器不会等待资源加载完成，直接返回包含fallback的HTML

2. 客户端水合行为：

   • 客户端接收到服务器渲染的HTML时，createResource的数据可能已经通过序列化传输完成
   • 水合阶段data.state立即变为'ready'
   • Show组件现在要渲染主内容而非fallback
   • 但DOM结构与服务器渲染结果不匹配，导致水合失败

解决方案

SolidJS核心团队成员明确指出，这种使用模式本身存在问题。正确的做法是：

1. 使用Suspense替代Show：

   <Suspense fallback={<p>Loading</p>}>
     <p>Loaded: {data()}</p>
   </Suspense>
   

2. 避免直接检查资源状态：

   • 不要使用data.state或data.loading作为条件渲染的依据
   • 让Suspense自然处理加载状态

技术原理深度解析

1. SSR与水合协调：

   • SolidJS的SSR需要确保服务器和客户端的渲染结果完全一致
   • Suspense机制能够保证两端的行为一致性
   • 直接检查资源状态会破坏这种协调

2. 资源序列化：

   • 服务器会将已完成加载的资源序列化到HTML中
   • 客户端水合时会反序列化这些数据
   • 这导致资源在客户端立即可用

3. 渲染时序问题：

   • 服务器渲染时资源未加载完成
   • 客户端水合时资源已可用
   • 使用状态检查会导致渲染路径不一致

最佳实践建议

1. 始终优先使用Suspense：

   • 对于异步数据加载场景，Suspense是最可靠的选择
   • 它专为处理SSR与水合协调而设计

2. 避免的状态检查：

   • 不要依赖loading、state等状态进行条件渲染
   • 这些状态会导致渲染路径不可预测

3. 复杂场景处理：

   • 对于需要更复杂逻辑的场景
   • 可以考虑在资源加载完成后才渲染组件
   • 或使用更高级的状态管理方案

通过遵循这些原则，开发者可以避免大多数SSR与水合相关的问题，构建出更健壮的SolidJS应用。