每当我在Redux存储中存储不可序列化的值时，我都会收到以下警告：
在下面的示例中，我存储了一个处于Redux状态的Firestore.Timestamp。Date对象也会发生这种情况。
在状态中检测到一个不可序列化的值，路径为：blogPost.createdAt。值：t｛秒：1583488258，纳秒：805000000｝
查看处理此操作类型的减速器：LOAD_BLOGPOstrongUCCESS。(请参见https://redux.js.org/faq/organizing-state#can-i-put-功能-承诺-其他-不可串行化-项目-在我的存储状态)
这就是医生所说的：
https://redux.js.org/faq/organizing-state#can-i-put-功能-承诺-其他-不可串行化-项目-在我的存储状态
我可以将函数、承诺或其他不可序列化的项放入存储状态吗
强烈建议您只将普通的可序列化对象、数组和基元放入存储中。从技术上讲，可以将不可序列化的项插入到存储中，，但这样做可能会破坏存储内容的持久化和再水合能力，并干扰时间旅行调试
如果您可以处理持久性和时间旅行调试等可能无法按预期工作的问题，那么完全欢迎您将不可序列化的项放入Redux存储中。最终，这是您的应用程序，如何实现它取决于您自己。与Redux的许多其他内容一样，请确保您了解其中涉及的权衡
我从上面的文档摘录中没有理解太多。我觉得有点含糊。有人能更详细地解释一下，通过向Redux状态添加不可序列化的数据，我们可能会/将会损失什么吗？
不同数据类型的结果是否不同？例如：Promise、function (ex: a React component)和Date会导致不同的问题？它肯定会引起问题吗？或者这是可能发生或可能不会发生的事情？
保持和补充商店内容物水分的能力 意味着什么？这是否意味着它可能会破坏我的应用程序代码，或者我们谈论的只是devtools调试？
更新
刚刚从Redux Toolkit中找到了另一篇文档：使用不可序列化数据。
使用不可序列化数据
Redux的核心使用原则之一是不应将不可序列化的值放入状态或操作中
然而，与大多数规则一样，也有例外。有时可能需要处理需要接受不可序列化数据的操作。这种情况应该很少发生，而且只有在必要时才发生，并且这些不可串行化的有效负载永远不应该通过reducer进入应用程序状态
可串行化的dev-check中间件在任何时候检测到您的操作或状态中的不可串行化值时都会自动发出警告。我们鼓励您保持此中间件处于活动状态，以帮助避免意外出错。但是，如果您确实需要关闭这些警告，您可以通过将中间件配置为忽略特定的操作类型或操作和状态中的字段来自定义中间件：
这几节似乎教你如何忽略操作中使用不可序列化值的警告，但它也说它不应该进入状态，对吧？
持久化和重新水合商店内容的能力意味着什么？这是否意味着它可能会破坏我的应用程序代码，或者我们谈论的只是devtools调试
可序列化数据，意味着您将数据转换为文本表示，然后将其从文本表示重新加载为实际类型；
持久化和重新水合商店内容物的能力平均
持久化和重新水合应用程序是一种用于存储当前应用程序商店状态的技术，以便在以后重新加载。假设您的用户正在处理某个复杂的表单，当他关闭浏览器并重新打开它时，您希望在表单中填写用户在上次会话中输入的内容，但没有将数据存储在后端服务器中。因此，当网页关闭时，你会保留你的反应存储，并在用户重新打开网页时重新加载它(从locastorage重新水合)
实际情况是，当你想从之前保存的数据中提取应用程序状态时，不可序列化的字段将不会被解析和转换为正确的类型(即使不可序列化，有时也可能工作)
因此，如果您不打算持久化和重新水合状态，您可以忽略该消息，但也可以为您的类型实现自定义序列化程序(例如，将时间戳转换为字符串)