关于V8脚本引擎，其实应用的领域比较广：比如 Chrome 浏览器、Node.js、Electron 以及 Deno 等。我们前端人员可能只把关注点放在了JavaScript或其他技术栈语法，单纯了解EventLoop，调用一些WebAPI。并不了解 V8 这个“黑盒”内部是如何工作的。
当了解JavaScript的执行原理时，我们也能更轻松理解Babel的语法分析和词法分析原理、ESlint的语法检查机制、Vue，React等框架的底层实现。我们就从这个引擎的历史和核心模块谈起。
当然，这也是一个非常大的话题，每一个环节都能写出一篇文章 隐藏类与内嵌缓存、内存管理垃圾回收机制、Extension机制，等待慢慢更新。今天先浅谈几个关键点：
1. V8脚本引擎的由来。
2. V8脚本引擎的演进。
3. V8核心模块：解析器，解释器，优化编译器。
V8脚本引擎的由来。
了解V8的诞生，我们要先了解JavaScript语言属于解释性语言。
-
支持动态类型，弱类型，在程序运行的时候才进行编译，效率较低。
-
不像编译性语言，源代码不能直接翻译成机器语言，先翻译成中间代码，再由解释器对中间代码进行解释运行。
-
程序不需要编译，程序运行时才翻译成机器语言，每执行一次都要翻译一次。
-
一般，
编译性语言的运行效率比解释性语言更高；但是不能一概而论，部分解释性语言的解释器通过在运行时动态优化代码，甚至能使解释性语言的性能超过编译性语言； 了解了js语言是由 源代码=>中间代码=>机器语言 执行的过程，并且js承担的工作越来越多，如果没有一个专用的脚本解释器来对其进行快速解析执行和优化的话，而仅靠之前webKit中默认的JavaScriptCore，那用户体验会越来越差。此时V8引擎就是未解决这些问题诞生的。
说到WebKit，在之前《浏览器到底都有什么？》一文中提到过渲染引擎有Trident，Gecko,Webkit等，我们主要聊聊Webkit引擎都包含什么，它又与js引擎是怎样的关系。
最早渲染引擎中就包含着对js的解释器，当时只是为了满足表单提交的简单功能，并没有那么强大。这是WebKit的大致结构介绍：
-
图中的实线框，虚线框代表什么：
实线框- 模块是所有移植的共有部分。虚线框- 不同的厂商可以自己实现。
-
操作系统- 是管理和控制计算机硬件与软件资源的计算机程序，是直接运行在“裸机”上的最基本的系统软件，任何其他软件都必须在操作系统的支持下才能运行。WebKit也是在操作系统上工作的。 -
第三方库- 为了WebKit提供支持，如图形库、网络库、视频库等。 -
WebCore- 是各个浏览器使用的共享部分,包括HTML解析器、CSS解析器、DOM和SVG等。JavaScriptCore- 是WebKit的默认引擎，在谷歌系列产品中被替换为V8引擎。WebKit Ports- 是WebKit中的非共享部分，由于平台差异、第三方库和需求的不同等原因，不同的移植导致了WebKit不同版本行为不一致，它是不同浏览器性能和功能差异的关键部分。
-
WebKit嵌入式编程接口 -供浏览器调用`，与移植密切相关，不同的移植有不同的接口规范。 -
测试用例，包括布局测试用例和性能测试用例，用来验证渲染结果的正确性。 那js引擎与渲染引擎的关系又是什么呢？
JavaScript语言是解释型语言，为了提高性能，引入了Java虚拟机和C++编译器中的众多技术。现在JavaScript引擎的执行过程大致是:源代码-→抽象语法树-→字节码-→JIT-→本地代码(V8引擎没有中间字节码)。而是将抽象语法树通过JIT技术转换成本地代码，放弃了在字节码阶段可以进行的一些性能优化，但保证了执行速度。
在这我们引出了V8引擎为何而生，js解释器与渲染引擎的关系，概述了一下解释的执行过程。下一章，我们来了解V8的演进过程，知道它在不同时期，都加入了哪些新功能，怎样更优雅的执行我们的js代码。
如果此文章对您有帮助或启发，那便是我的荣幸
