您的问题中有很多问题，其中一些完全不相关，但假设问题是“不匹配”的 DCU 不太可能是正确的（我认为您的意思是在过去或不同来源）。
首先是你的问题。
IDE 行为
在项目管理器中双击单元时 IDE 锁定的问题不太可能与“不匹配”的 DCU 有关。
您有位于网络驱动器上的源文件吗？这个单位是这样的文件吗？该网络位置是否可用/有效？即文件的路径是否使用不再映射或不可用的网络驱动器号？
如果 DPR 中的单元引用中没有明确的路径，您的系统、IDE 或项目 PATH 中是否列出了网络位置？
难以访问文件位置是 IDE 在尝试简单打开文件时出现锁定的最可能解释。
至于为什么在使用 F12 而不是项目管理器时它的行为会有所不同，不幸的是，Delphi IDE 因使用不同的机制在不同的地方实现相同的事情而臭名昭著，所以有时当使用其中一种机制时，这并不奇怪打破其他仍然有效（即使两者都有效，也会给出不同的结果）。
应用的运行时行为
如果我们的工作是基于您确实有一个“不匹配”的 DCU，那么只要您拥有所有必需 DCU 的源并且 为每个 DCU 提供正确的和适当的源。
但是，即使不匹配问题可能得到解决，重建也可能会或可能不会解决问题，这取决于重新编译时该问题是否仍然存在于该单元本身的源代码中。
DCU“不匹配”这一简单事实不会导致异常的应用程序行为。除了 OS 或 RTL 错误等，如果应用程序的行为存在错误，那么这些错误将是编译时源代码中的错误的结果。
简单地重新编译包含错误的源代码不会消除该错误。
因此，如果有这样的错误，那么如果有人能够在该分数上提供任何帮助，则需要更多信息（这应该是一个单独的问题，一旦你自己进行了一些初步调试和诊断）。
运行时包
如果您使用的是运行时包，那么事情会变得更加复杂，因为使用运行时包时，用于任何特定单元的 DCU 都可能是包文件的一部分。在这种情况下，磁盘上的 DCU 文件是在编译包本身时生成的，但是使用的任何项目包将不会 使用磁盘上的 DCU，但将使用已编译到包中的版本。
因此，如果您正在使用运行时包，那么除了重建您的项目之外，您还需要重建所有可能已更改的运行时包。
现在，针对您的实际问题。
Q1：我可以重建所有的 DCU 吗？
是的，当然。但是请参阅上面的 w.r.t Runtime Packages，如果您的项目使用它们。
我强烈建议您更改项目设置，将 DCU 文件输出到特定位置，与源文件分开。
例如，您可以拥有一个使用相对路径的项目特定 DCU 文件夹。即将 DCU 输出文件夹设置为“.\dcu”之类的内容，并在 DPR 所在的文件夹中创建一个 dcu 文件夹。
对于支持多个平台和配置的 Delphi 版本，最好在该路径中包含平台和配置的环境变量，这样您就不会在 RELEASE 构建中使用为 DEBUG 编译的单元。
例如
.\dcu\$(Platform)\$(Config)
或
.\$(Platform)\$(Config)\dcu
构建中编译了什么？
当您对项目执行构建（不同于“编译”）时，该项目引用的所有单元都将被重新编译，但任何 VCL/RTL 单元除外（即那些由 Delphi 提供）。那些会得到特殊待遇。
重建项目至少会强制重新编译 DPR 中明确列出的所有单元，但也会重新编译这些单元（或它们使用的单元等）使用的 所有 其他单元.
注意：DCU 缺少源
一个单元只有会被重新编译如果 源可以被定位。
如果您有一个 DCU 并且源文件丢失或无法在项目、IDE 或系统路径上找到，那么编译器将简单地假定您要使用现有的 DCU。
即使是完整的“构建”也是如此。
第三方 DCU
这似乎很明显，但您也应该注意不要删除 DCU，因为它可能是您可能正在使用但没有源代码的任何 3 方库的唯一副本。
这是非常不可取的，但我想我们不能排除您可能处于这种情况的可能性。
Q2：我应该删除所有 DCU 吗？
一般来说，是的。如上所述，如果您缺少引用的单元的源代码，即使完整构建也会成功，只要存在可以找到的 DCU（或所需的包，如果使用运行时包）。
因此，确保您拥有所有 DCU 的当前来源的唯一方法是首先删除任何先前版本可能使用过的 DCU。
当您有一个特定的、明确的位置来输出您的所有项目 DCU 时，这当然会容易得多。
如果您使用的是运行时包会稍微复杂一些，但如果您要合理地组织 DCU，那么唯一真正的复杂情况是您需要重复相同的练习对于所有涉及的项目，通过启动每个使用的运行时包并完成依次使用它们的项目。