这个问题现在已经有大约 2 年了（对我来说）。目前的答案是：做不到。
我正在使用git，但我相信这并不取决于您使用的是哪一个，即使它是资产服务器。
正在遵循手册中的所有内容以及我发现的内容。
库重建可能需要几分钟甚至几小时的时间，具体取决于 Unity 认为它需要多少工作。
虽然这不是一个关键问题（它不会停止工作流程），但它仍然很大。由于这个问题，我们没有完全使用 git。回到历史中旧的提交是不切实际的，甚至简单地更改并行分支都可能成为一场噩梦。所以我们总是避免这样做，除非它很关键。
有很多事情会触发库重建，这里有一些已知的：
- 触摸文件。这里不费吹灰之力。你触摸的越多，花费的时间就越多。
- 在 Unity 之外移动/重命名文件。如果它们是视频文件，则特别明显。
- 在 git 中保留时间戳是不够的。至少以我能做到的方式。
- 每当我们在新机器中签出时 - 这将添加额外的库重建，因为最终必须将构建平台设置更改回 Android 或其他任何设置。
问题在标题中：如何防止图书馆继续这样重建自己？
至于一些看似合理但无效的答案......
如果我同时提交库，这将不起作用，因为即使只是在打开 Unity 之前签出旧的提交并返回到相同的提交也会触发库重建。
称为"缓存服务器"的"库网络缓存"不能解决任何问题。它确实使它更快，有时，特别是为了在新机器上签出。但这仍然远非好事。它仍然可能需要长达数小时的时间。
由于将文件滚动到旧版本，然后立即返回到最新版本会触发重建，我只能想象 Unity 至少会查看文件的时间戳。它可能还会查看树 - 哪些文件存在等，并且可能使用内容的哈希值，甚至是树结构。
在Unity 关闭的情况下，以保留时间戳的方式将整个资源树复制到第二个位置，然后签出旧提交，然后再次签出当前提交，然后将副本复制回它，再次保留时间戳，这会很有趣。然后打开 Unity 并查看它是否要重建。如果是这样，我不知道它是如何确定它需要这样做的（将文件驻留在磁盘上的位置存储在块级别？
如果它有效，它只会允许你一个技巧 - 检查旧的提交，然后再次检查当前的提交 - 而不会干扰事情。但是，它不会让您只进行旧提交而不重建，因为旧提交将没有时间戳，即使您在旧文件上伪造它们，新/移动/删除的文件、校验和等，也可能生成重建。
另一种选择是找出 Unity 在后台在哪里做它的事情，然后将其（或几个）包装在一个 git 存储库（或几个）中。这将允许您在库重建之前、期间和之后对它们进行git status，以查看它到底在做什么。然后，您实际上可以将时间戳技巧与记录 Unity 创建的资产 blob 的第二个存储库混合在一起，并编写脚本以协同工作，以防止 Unity 注意到更改。
我需要更多信息才能走得更远。我已经有几年没有使用Unity了。