在VS2012（以及之前的版本...）中，您可以在构建项目时指定目标平台。不过，我的理解是，C# 被“编译”为 CIL，然后在主机系统上运行时被 JIT 编译。
这是否意味着指定目标平台的唯一原因是故意限制用户在某些架构上运行软件或强制应用程序在 64 位机器上以 32 位运行？我看不出这与优化有关，因为我猜这发生在 CIL--> Native 阶段，这发生在主机架构上的 Just-In-Time 阶段？
这个 MS Link似乎没有提供任何替代解释，我找不到任何建议，例如，您应该发布同一应用程序的单独 32 / 64 位版本 - 为“anycpu”编译的东西似乎合乎逻辑应该同样运行，并且优化将再次应用于 JIT 阶段。
这是否意味着指定目标平台的唯一原因是故意限制用户在某些架构上运行软件或强制应用程序在 64 位机器上以 32 位运行？
是的，如果您将本机代码与托管代码混合使用，这一点至关重要。但是，它不会改变在运行时优化的内容。
如果您的代码是 100% 托管的，那么 AnyCPU（或新的 AnyCPU Prefer 32-Bit）可能没问题。编译器优化将相同，JIT 将在运行时基于当前执行平台进行优化。
我找不到任何建议，例如，您应该发布同一应用程序的单独 32 / 64 位版本
除非您与非托管代码执行互操作，否则没有理由这样做，在这种情况下，这将需要单独的 32 位和 64 位 DLL。
里德在这里有一个很好的答案。然而，我认为同样重要的是要指出这个设置只是 DLL 中的一个标志 -在大多数情况下它几乎没有任何影响。运行时加载程序（启动 .NET 运行时的本地代码位）负责查看此标志，并指示要启动的 .NET 运行时的适当版本。
正因为如此 - 该标志主要只在它设置在 EXE 文件上时才重要 - 而在 DLL 上设置时没有效果。例如 - 如果您有一个由 64 位标记的 .NET EXE 或任何 CPU 标记的 .NET EXE 使用的“32 位标记的 .NET DLL”，并且您在64 位机器 - 然后加载程序将启动 64 位运行时。当需要加载 32 位 DLL 时，为时已晚 - 已经选择了 64 位运行时，因此您的程序将失败（我相信您将收到 BadImageFormatException）。