hydrate有landed to React 16，但尚未记录其用途。
This article表示它应该与renderToNodeStream一起使用，但不会提供太多细节。
hydrate的预期用量是多少？
renderToString是同步的。它也不能处理重新渲染的组件，即在初始渲染期间在组件状态中发生同步（即相同的滴答）变化并且应该触发额外的render调用。示例是需要a workaround的Helmet，以便将更改从嵌套Helmet传播回服务器端的顶级组件。
hydrate和renderToNodeStream可以帮助避免renderToString限制并在服务器端呈现异步和/或重新呈现的组件吗？
答案 0 :(得分：3)
hydrate的使用不仅限于renderToNodeStream - 您可以（实际上也应该）将其与经典renderToString一起使用。 renderToNodeStream与renderToString基本相同，只是它生成一个http流而不是一个字符串。这意味着您可以在渲染期间将呈现的html发送到客户端逐字节，这与标准renderToString相反，当您必须等待首先渲染整个html字符串时，只有在你把它发送给客户之后。
ReactDOM.hydrate是标准ReactDOM.render的替代品。基本（和唯一？）的区别在于，与ReactDOM.render相反，如果客户端上的React的校验和与计算的校验和不匹配，则它不会丢弃所有DOM。服务器。它试图通过修补不同的部分，将React客户端应用程序附加到服务器呈现的DOM，即使存在一些细微差别。
由于renderToNodeStream的流媒体特性，在图书馆的当前状态下，Helmet的服务器端使用几乎是不可能的 - DOM的head部分被发送到服务器当React计算包括Helmet组件在内的DOM时。该流无法恢复并将Helmet的更改附加到head。
总而言之，回答你的问题 - renderToNodeStream解决了通过发送流同步渲染到字符串的问题，但它引入了新的问题，即如果React App的某些其他部分无法修补推送的内容需要它。它在服务器端的状态更改和重新呈现方面没有添加任何内容。另一方面，hydrate并未在此主题中引入任何新内容 - 它只是旧版render的一个更加宽容，更宽容的版本。
官方文档解释了很多！ https://reactjs.org/docs/react-dom.html