是否有任何经验法则可以决定何时何地erlang:make_ref/0优先选择erlang:unique_integer/0,1或相反？
make_refs 上的大多数示例似乎都围绕消息或请求。在这些情况下，引用是短暂的，并且可以将 make_refs 替换为 unique_integer 而不会遇到太多麻烦。
速度或保证方面有区别吗？当尝试识别将持久保存和/或与其他系统交换的长期对象或数据时，是否应该优先选择其中一个？
unique_integer([monotonic])需要在调度程序之间同步，因此它们比非单调unique_integer或make_ref.
两者都是非单调的unique_integer，并且make_ref使用类似的方式来构造自己，使用每个调度程序专用的池。但是，unique_integer池始终以相同的值启动，而参考池使用当前时间作为种子。
而且， 的保证unique_integer仅与当前节点相关。您可以连续运行erl -eval 'io:format("~p", [erlang:unique_integer()]),init:stop().'几次，您将看到重复的值。因此，如果您有一个集群，则整数可能不是唯一的。
另一方面，由于引用包括创建它们的节点，因此它们在集群中连接的节点中是唯一的。
使用持久化数据时，您需要考虑可能的 ERTS 重启，因此无法有力地保证时间上的唯一性。尽管使用引用可能就足够了（正如我已经表明的那样，unique_integer在考虑节点重新启动时这还不够强大），但也许您应该使用不同的策略，例如在存储数据时让持久层为您创建 id（AUTOINC in MySQL）。
但您可以根据需要混合搭配这些。您可以让每个节点在启动时从持久层中提取一个唯一的整数（我们称之为node-id），并将其与unique_integer更大的整数组合。node-id或者，您可以让每个节点结合启动时间、强随机性和自己名称的哈希值生成自己的节点......这一切都取决于您的用例的要求。