Next.js中pageProps与props差异及Hydration状态重复问题咨询

这个现象其实是完全正常的，不用太担心——这两个工具的Hydration机制本来就是独立运作的，各自维护着自己所需的状态，并非逻辑重复。

为什么会出现两个不同的Hydration属性？ #

• next-redux-wrapper：它的核心作用是在服务端渲染时，把你整个Redux store的状态序列化，注入到页面的全局对象中（通常是__NEXT_REDUX_STATE__）。这样客户端初始化Redux时，就能直接复用服务端已经计算好的状态，避免客户端重新计算导致的页面不匹配问题。这部分存储的是你的全局应用状态，包括业务数据、用户状态等所有存在Redux里的内容。
• next-i18next：作为多语言解决方案，它需要在服务端就确定当前请求的语言环境，加载对应语言的翻译数据，然后把这些信息（当前语言、已加载的翻译命名空间等）序列化注入到页面（一般是__NEXT_I18NEXT__）。客户端初始化i18n实例时，会读取这些信息来同步服务端的语言状态，确保页面渲染时不会出现语言跳转或翻译缺失的问题。这部分存储的是多语言专属的配置和数据，和Redux的全局状态职责完全不同。

关于服务端性能的担忧 #

如果你的两个属性里存储的是各自职责范围内的数据，那其实不存在“不必要的重复”：Redux存的是你的业务状态，next-i18next存的是语言相关的配置和翻译，两者内容并不重叠，服务端的序列化操作开销非常小，不会对性能造成明显影响。

不过如果你发现确实有重复数据（比如你在Redux里也存了完整的翻译内容，而next-i18next又单独存储了一份），那可以考虑优化：

• 可以尝试让next-i18next和Redux联动，比如通过适配工具让i18n的状态直接存在Redux中，这样next-i18next就不需要单独注入Hydration状态了，但这会增加一些配置复杂度，需要权衡是否值得。
• 检查你的Redux state，是否真的需要存储翻译数据——通常next-i18next已经负责了翻译的加载和管理，Redux只需要存储当前语言标识即可，这样就能避免重复存储大体积的翻译内容。

总的来说，默认情况下两个工具各自生成Hydration状态是正常的设计，只要没有冗余的重复数据，就不用纠结服务端的额外操作~

内容的提问来源于stack exchange，提问作者UKRman