IndexedDB的W3C规范将a key generator定义为：
每次需要密钥时，密钥生成器都会生成单调递增的数字[sic]。
现在，似乎（对我而言）IndexedDB的常见用例（或者，就此而言，任何HTML5客户端存储选项：WebSQL，localStorage等）都是设计为脱机工作的应用程序（在与HTML5 ApplicationCache合作。
在此方案中，已断开连接的 Web应用程序可能会在其本地数据存储中生成新对象/记录，这些对象/记录稍后会在与服务器的连接可用时同步到集中式数据库。
此外，任何多个客户端同步到相同集中式数据库的应用程序通常都需要一种机制来防止ID冲突。
UUID（或GUID）是一个不错的选择，因为它可以在没有任何中央协调的情况下实现唯一密钥生成。相比之下，“单调递增数字”是一个糟糕的解决方案（除非每个客户端都“播种”了一个不太可能与其他用户发生冲突的起始值）。
我发现IndexedDB规范没有指定（甚至允许将来支持）备用密钥生成器（例如UUID生成器），这令人惊讶。有些人可能会建议答案根本就是不要使用IndexedDB的内置密钥生成器，而是让应用程序生成自己的密钥。
然而，虽然有很多基于Javascript的UUID生成器可用，但其中许多似乎都是基于Math.random（），它已经知道了 randomness 方面的限制，所以可能没有如果必须保证绝对唯一的密钥，那么这是一个很好的选择。
由IndexedDB实现者提供的本机UUID生成器（可能）将比应用程序实现/导入的脚本更强大并且性能更好;人们会想。
我在这里错过了什么，或者W3C IndexedDB工作组错过了这个机会？
答案 0 :(得分：0)
这是一个非常充满问题的问题但是，如果您在使用IndexedDB几年后想要我的想法，我会说UUID API会很好但是它似乎超出了工作组的范围实现。
UUID同名，“普遍”独特。 IndexedDB中唯一性的最高概念是对象存储，数据级别和浏览器级别的数据库。
在实践中，我喜欢在新数据库或对象存储上重新运行代码时可以获得可预测的，可重复的结果。虽然我可以看到我希望在所有客户端dbs中保持唯一性的情况，但我绝对不希望它成为默认值。
我个人并不要求我的客户端数据库具有通用唯一性，但是，无论如何，如果你这样做，可以使用很棒的UUID JS实现。
答案 1 :(得分：0)
objectStore键对于本地数据库中的objectStore是唯一的，没有别的。关于唯一性的任何更高级别的语义都超出了IndexedDB的范围。您描述了UUID，但即使这只是一种形式的唯一键。有许多不同的方法来生成具有不同属性的UUID，包括特定前缀与单调增加的低位相结合，随机生成整个内容，通过以太网卡地址确定范围等。
通过选择仅限于本地实例的内容，IDB（无论好坏）迫使开发人员仔细选择“全局”唯一键。