indexedDB：“_proto_”在数据库对象中做什么？

Question

对象在 indexedDB 中的存储方式是否发生了变化，至少在 Firefox 中是这样？

我现在注意到在开发人员工具存储选项卡中出现了“_proto_”。直到我在我的程序中观察到我无法弄清楚的奇怪行为之前，我并没有多想它。

我认为对象在被写入数据库之前被克隆，这样，无论它们是如何创建的，它们都是独立的。例如，在第一次创建数据库时，添加了一些映射对象；并且，由于多个对象具有完全相同的布局/结构，因此将重复使用对单个对象的引用，如下所示。

加载页面时，映射数据被读入 RAM 并用于管理数据库键的分配。除非我真的很困惑，否则 prop_3 到 prop_7 似乎在稍后重新加载页面时从数据库中提取时保留了公共引用，这样如果 prop_3 中的一个属性被更新，相同的属性也会在 prop_3 到 prop_7 中更新。

这是它应该工作的方式吗？我希望 prop_3 到 prop_7 在写入数据库和从数据库读取之后不再共享公共引用。

如果这是准确的，对象可以以不保留这些类型的共享引用的方式写入数据库吗？当然，我意识到可以不使用对 repeated_object 的引用来对它们进行不同的分配；事实上，这为我解决了具体问题。谢谢你。

repeated_object = { ...property : value... };

os.add( { 'prop_1' : 1, 

          'prop_2' : 2,

          'prop_3' : repeated_object, 

          'prop_4' : repeated_object,

          'prop_5' : repeated_object,

          'prop_6' : repeated_object,

          'prop_7' : repeated_object  } );

Answer 1

对未写入数据库的对象的引用如何序列化？当从数据库中检索该示例对象时，最后五个属性仍被视为对同一单个对象的引用。是的，这是预期的。IndexedDB不使用类似的东西JSON.stringify(value)，如果它被多次引用，就会多次序列化一个对象。相反，它使用结构化克隆，它不仅支持序列化更多类型，还支持循环或共享引用。这是 Firefox 的新功能吗？不，这应该在所有浏览器中保持一致。它完成了_proto_吗？一点都不。这与它无关。结构化序列化不保留原型对象（内置对象除外）。