我最近了解到 JIT 编译器用于将独立于平台的代码编译为本机代码。JVM 和 .net 运行时环境使用它，以获得更好的性能并显着减少编译时间。我的问题是，为什么不把直接编译成本机代码的普通编译器（如 c 编译器）也做成 JIT？如果使用 JIT 编译器，是否有使用限制或规范？
JIT 有优点也有缺点。如果您将软件部署到许多不同的 PC，JIT 会非常有用，因为 JIT 编译器可以检测如何针对每个特定平台优化代码。
问题在于，JIT 增加了软件首先执行之前必须执行的另一个步骤：首先必须将其编译为 IL，然后将其编译为机器代码，这意味着额外的性能开销。然而，这种从 IL 到机器代码的转换只需在软件第一次运行时完成，因此后续的每次调用都会快得多。
所以基本上（根据经验）你可以说：如果软件是一个长时间运行的进程，那么使用 JIT 通常是好的，如果软件的生命周期很短，那么最好使用本机代码。
现代 javascript 实现也执行 JIT，某些 PHP、Python 和 Ruby 实现也是如此（至少）。然而，JIT 的技巧在于它们是相对较新的开发，其工作的部分原因是您依赖于最终用户计算机上的某种类型的框架或运行时，该框架或运行时能够执行正确的操作。针对该机器和应用程序实例的优化。
对于想要接近计算机“裸机”的语言，依赖额外的抽象层并不总是有意义。
JIT 的另一个问题是它会增加应用程序的启动时间。自最初的答案以来，软件开发作为一个整体已经更多地转向云和持续集成/部署，其中纯冷启动更为常见，并且 JIT 预编译步骤所用的时间对于感知性能绝对重要不是过去。
这就是为什么，例如，历史上一直致力于 JIT 的 .Net，在最近的版本中在更好的 AoT（提前）支持方面取得了长足的进步。