假设我有两个名为Car和Wheel的JSON对象。汽车有一个轮子的集合，其余都是原始类型的属性。
汽车：
轮式：
现在，如果我想用localStorage保存这款车，我有两种选择。
我在第一个解决方案中看到的缺点是，如果我在代码中重命名轮子属性，我将丢失先前存储的数据，而通过Id引用和检索单独的轮子则不会。另一方面，第二个解决方案更像是一个关系数据库，而不是面向对象的JSON所针对的。
我的问题是：我可以最好地使用这种存储器，为什么？
答案 0 :(得分：1)
我认为你应该使用两种解决方案的一部分并有所作为，在哪里使用哪个选项：
将它们作为分隔对象（第二个选项）保存到localStorage，并且只保留car对象中的引用，因此您将保持它们干燥。然后，您可以在代码中重命名该属性，而不会丢失引用和将来。您还可以通过更加语义的方式仅为了将来的目的访问轮子。
在代码中进行抽象，在这里对两个对象进行序列化和反序列化并将它们连接到那里（如第一个解决方案中所需）。所以JSON仍然很干净，你将获得连接解决方案的所有优势。
不幸的是，你当然知道，没有最好的选择。这取决于您的直觉和对数据未来的预测。抽象可以帮助你，因为大多数时候，以后你可以重构某些东西，你可能会。
答案 1 :(得分：0)
我也考虑过这一点，并测试了存储大列表和分别存储列表项之间的性能差异。我认为这足以为后来者提供一些建议。
从性能的角度来看，除非您始终了解localStorage的键并且一次只需要几个项目，否则序列化和存储整个对象树的速度通常快10倍。
考虑到localStorage的存储容量较小，并且平面对象需要一些其他结构，因此平面对象可以存储的内容实际上会减少。平面对象似乎可以通过共享项目来节省存储空间，但是同样的事情可以在单个对象中完成，只要看看人们如何使用Redux。
此外，平面对象还需要克服“引用被用户破坏”的风险，因此还需要垃圾回收功能。
结论：存储整个对象。如果您坚持要存储平面对象，那么即使IndexedDB也会更好。