我是否正确地说JavaScript代码没有编译，甚至不是JIT？如果是这样，这是否意味着评论会对绩效产生影响，我应该非常小心地将评论放在哪里？比如在可能的情况下在函数定义的上方和外部放置函数注释，并且如果我想最大化性能，肯定避免在循环中放置注释？我知道在大多数情况下（至少在非循环的情况下），性能的变化可以忽略不计，但我认为这将是一个很好的知识和意识，特别是对于前端/ js开发人员。另外，我最近对js评估提出了一个相关问题。
我是否正确地说JavaScript代码没有编译，甚至不是JIT？
虽然JavaScript传统上是一种“解释”语言（尽管不一定如此），但大多数JavaScript引擎会在必要时即时编译它。 V8（Chrome和NodeJS中的引擎）用于立即快速编译，然后返回并积极优化任何使用过的代码（旧的FullCodegen + TurboFan堆栈）;前一段时间做了大量的实际测量，they switched最初解析为byteocde和解释，然后编译代码是否重复使用（新的Ignition + TurboFan堆栈），通过不编译运行获得显着的内存节省 - 一旦设置代码。即使是攻击性较低的引擎，几乎可以肯定至少会将文本解析为某种形式的字节码，尽早丢弃注释。
请记住，“解释”与“编译”通常更像是环境事物而不是语言事物;有C语言解释器，还有JavaScript编译器。语言往往与环境紧密相关（就像JavaScript与Web浏览器环境的关系一样，即使它总是被广泛使用，甚至早在1995年），但即便如此（如我们所见），可能有变化。
如果是这样，这是否意味着评论会对绩效产生影响......
在初始解析阶段，非常非常非常小的一个。但评论很容易扫描过去，没有什么可担心的。
但是，如果您真的担心它，可以使用jsmin或Closure Compiler等工具缩小您的脚本（即使只进行简单的优化）。前者只会删除评论和不必要的空白，这样的东西（仍然非常有效）;后者这样做，实际上理解代码并做一些内联等。因此，您可以自由发表评论，然后使用这些工具确保使用缩小工具绕过首次加载脚本时这些注释可能产生的微小影响。
当然，关于JavaScript性能的事情是，很难可靠地预测跨引擎，因为引擎变化很大。所以实验很有趣：
结果？我的看法是测试的测量误差中没有明显的差异。
评论的最大影响是膨胀文件大小，从而减慢脚本的下载速度。因此，为什么所有专业网站都使用最小化器来生产高效版本，将js缩小到最小。
它可能会有一些影响。虽然非常简约的效果（甚至IE6正确处理评论！待确认......）。
但是，大多数人使用缩小评论的缩小器。所以没关系。
也：
V8通过在执行之前将JavaScript编译为本机机器代码来提高性能。
它can prevent functions from being inlined，影响性能，虽然这不应该真的发生。