Answers:
由于以下原因，尽早解决此问题要容易得多，以免积累技术债务。即使您发现自己已经处在这种情况下，在不远的将来处理它也可能比让它继续构建要好。
这个问题似乎集中在具有本地文件系统的机器之间传输文件的范围狭窄，这允许机器特定的所有权状态。
联网文件系统考虑因素很容易成为试图使UID / GID映射保持同步的最大案例，因为通常您可以在输入图片时在窗口中提及您提到的“否则实现”。当然，你可能没有这些主机之间共享文件系统的联网，现在关于未来......但什么？可以诚实地说，永远不会在您当前的主机之间或将来创建的主机之间引入网络文件系统的用例？假设不那么具有前瞻性。
假设/home是之间共享的文件系统的网络host1和host2在下面的实施例。
/home/user1在每个系统上均由不同用户拥有。这使用户无法跨系统一致地访问或修改其主目录。host2会破坏对的权限host1。在有人退后一步并意识到正在进行一场拔河比赛之前，有时可能需要处理其中几张票。唯一的解决方案是修复不一致的ID映射。这导致...user1ID为user2，但user2ID为user17...，这只是集群中的第一个系统）等待解决问题的时间越长，这些链就越复杂，通常需要在多台服务器上关闭应用程序为了使事情正确同步。user2在host2具有相同的UID user1上host1，让他们写/home/user1在host2不知情的情况下user1。然后在host1的许可下评估这些更改user1。可能出什么问题了？（如果user1是一个应用程序的用户，有人在开发会发现它是可写的，并会做出改变。这是一个时间证明的事实。）还有其他方案，这些只是最常见的示例。
根据数字ID编写的任何脚本或配置文件在您的环境中固有地无法移植。通常这不是问题，因为除非绝对需要它们，否则大多数人不会对它们进行硬编码...但是有时候，您使用的工具无法为您提供选择。在这些情况下，您不得不维护n个不同版本的脚本或配置文件。
示例：pam_succeed_if允许您使用，和...的字段user，显然没有“组”选项。如果您被放置在期望多个系统实施某种形式的基于组的访问限制的位置，那么PAM配置将有n种不同的变化。（或至少一个避免碰撞的GID）uidgid
natxo的回答涵盖了这一点。
一旦达到一定大小（并且总是比您想像的要早），您将意识到，更改密码或为所有主机上的某人禁用帐户是PITA。这就是为什么人们使用像openldap或当今出色的freeipa之类的具有LDAP数据库（或NIS，但现在不这样做，现在不安全）的系统的原因。
您将所有帐户/组信息维护在中央数据库中，所有主机都共享该信息。您可以从那里进行更多操作：当然，可以使用用户信息获取文件许可权，还可以为所有具有ldap绑定的应用程序创建虚拟用户，而不必在那里也创建用户（许多Web应用程序都可以使用ldap为其用户数据库），维护中央sudo规则数据库，分发autofs环境，保留dns区域，...