浏览器工作原理和实践

参透了浏览器的工作原理，可解决80%的前端难题.

帮助高效快速安全开发web前端项目.

课程目录

开篇词 (1讲)

开篇词 | 参透了浏览器的工作原理，你就能解决80%的前端难题

宏观视角下的浏览器 (6讲)

01 | Chrome架构：仅仅打开了1个页面，为什么有4个进程？

02 | TCP协议：如何保证页面文件能被完整送达浏览器？

03 | HTTP请求流程：为什么很多站点第二次打开速度会很快？

04 | 导航流程：从输入URL到页面展示，这中间发生了什么？

05 | 渲染流程（上）：HTML、CSS和JavaScript，是如何变成页面的？

06 | 渲染流程（下）：HTML、CSS和JavaScript，是如何变成页面的？

浏览器中的JavaScript执行机制 (5讲)

07 | 变量提升：JavaScript代码是按顺序执行的吗？

08 | 调用栈：为什么JavaScript代码会出现栈溢出？

09 | 块级作用域：var缺陷以及为什么要引入let和const？

10 | 作用域链和闭包 ：代码中出现相同的变量，JavaScript引擎是如何选择的？

11 | this：从JavaScript执行上下文的视角讲清楚this

V8工作原理 (3讲)

12 | 栈空间和堆空间：数据是如何存储的？

13 | 垃圾回收：垃圾数据是如何自动回收的？

14 | 编译器和解释器：V8是如何执行一段JavaScript代码的？

浏览器中的页面循环系统 (6讲)

15 | 消息队列和事件循环：页面是怎么“活”起来的？

16 | WebAPI：setTimeout是如何实现的？

17 | WebAPI：XMLHttpRequest是怎么实现的？

18 | 宏任务和微任务：不是所有任务都是一个待遇

19 | Promise：使用Promise，告别回调函数

20 | async/await：使用同步的方式去写异步代码

浏览器中的页面 (8讲)

21 | Chrome开发者工具：利用网络面板做性能分析

22 | DOM树：JavaScript是如何影响DOM树构建的？

23 | 渲染流水线：CSS如何影响首次加载时的白屏时间？

24 | 分层和合成机制：为什么CSS动画比JavaScript高效？

25 | 页面性能：如何系统地优化页面？

26 | 虚拟DOM：虚拟DOM和实际的DOM有何不同？

27 | 渐进式网页应用（PWA）：它究竟解决了Web应用的哪些问题？

28 | WebComponent：像搭积木一样构建Web应用

浏览器中的网络 (3讲)

29 | HTTP/1：HTTP性能优化

30｜HTTP/2：如何提升网络速度？

31｜HTTP/3：甩掉TCP、TLS 的包袱，构建高效网络

参考：

https://blog.csdn/william_n/article/details/123175716

浏览器安全 (5讲)

32 | 同源策略：为什么XMLHttpRequest不能跨域请求资源？

33 | 跨站脚本攻击（XSS）：为什么Cookie中有HttpOnly属性？

34 | CSRF攻击：陌生链接不要随便点

35 | 安全沙箱：页面和系统之间的隔离墙

36 | HTTPS：让数据传输更安全

该专栏已经学习了两遍, 挺好的,  感觉还需要后续学习第三遍, 并结合其他资料, 以及前端项目一起学习消化, 融化贯通    ///  20210305 12:20 周五 家里

Note:

含记名不记名网友问题

& chatgpt

1 回顾浏览器的进化路线，你认为推动浏览器发展的主要动力是什么？

[一个角度来说，最大动力就是chrome的出现。曾经的IE像极了诺基亚，chrome就像是横空出世的iPhone ，当着IE的面告诉IE，浏览器应该这么玩儿。
另一个角度也是互联网的发展需要，人们所需要的不再是只是简单展示个页面的浏览器，需要有复杂的交互，浏览器应该能做更多的事情，这对浏览器的稳定性、以及性能都有了新的要求。所以出来一个性能符合要求的浏览器也是必须的。
还有就是11年后相对规范的es5的出现，再之后es6.7，web能做的事情越来越多了，web工程化，再后来node的出现，前端体系越来越庞大]

2. 07 | 变量提升：JavaScript代码是按顺序执行的吗？

1.老师好，请教您一个问题。

debugger;
(function(){
    console.log(g)
    if(true){
        console.log('hello world');
        function g(){ return true; }
    }
})();

这个函数步进调试时，发现打印g时值是undefined而不是提示not defined，说明if中g函数确实是提升了，但是为何不是g()而是undefined？然后走完function g(){ return true; }这一步后 console.log(g)中的g才变为g()。这里条件声明函数的变量提升有点搞不明白。
作者回复: 

ES规定函数只不能在块级作用域中声明，

function foo(){
    if(true){
        console.log('hello world');
        function g(){ return true; }
    }
}

也就是说，上面这行代码执行会报错，但是个大浏览器都没有遵守这个标准。

接下来到了ES6了，ES6明确支持块级作用域，ES6规定块级作用域内部声明的函数，和通过let声明变量的行为类似。

规定的是理想的，但是还要照顾实现，要是完全按照let的方式来修订，会影响到以前老的代码，所以为了向下兼容，个大浏览器基本是按照下面的方式来实现的：

function foo(){
    if(true){
        console.log('hello world');
        var g = function(){return true;} 
    }
}

这就解释了你的疑问，不过还是不建议在块级作用域中定义函数，很多时候，简单的才是最好的。

1.允许在块级作用域内声明函数。
2.函数声明类似于var，即会提升到全局作用域或函数作用域的头部。
3.同时，函数声明还会提升到所在的块级作用域的头部。

这里的表现应该是这样：
function foo(){
    var g1;
    if(true){
        function g2(){return true;}
        console.log('hello world');
        g1 = g2;
    }
}

g1和g2表示引用不一样，这里是同名关系，但是所在的变量作用域是不一样的。

下面这个文章详细解释了。
https://juejin.im/post/5eaa8211e51d454de64e388e
 

3. 老师，可以请教下吗，在编译完成之后是单单生成了字节码，再到执行过程中变成对应平台的机器码？ 还是编译过程已经生成了对应平台的机器码， 执行阶段就直接去执行相应的机器码？
作者回复: 先是生成字节码，然后解释器可以直接执行字节码，输出结果。 但是通常Javascript还有个编译器，会把那些频繁执行的字节码编译为二进制，这样那些经常被运行的函数就可以快速执行了，通常又把这种解释器和编译器混合使用的技术称为JIT

3. DOM API和BOM API

DOM(Document Object Model) 和 BOM(Browser Object Model) 是浏览器中用来操作网页的两个 API(应用程序编程接口)。

DOM API 是用于解析和操作 HTML、XML 等文档的 API，它提供了一个抽象层次结构来模拟文档的结构和内容。通过 DOM API，开发人员可以使用脚本将数据插入、修改和删除文档中的元素，以及遍历文档树、提取信息等。DOM API 主要由 JavaScript 语言提供，但也可以使用其他编程语言实现。

BOM API 是用于操作浏览器窗口和浏览器对象的 API，它提供了访问浏览器窗口、导航栏、状态栏、标签栏等的 API。BOM API 提供了与浏览器相关的操作，如打开新窗口、关闭窗口、切换标签页等。BOM API 主要由 JavaScript 语言提供，但也可以使用其他编程语言实现。

DOM 和 BOM 是浏览器中用来操作网页的两个重要 API，它们为开发人员提供了访问和操作网页的机制，从而可以更方便、更高效地编写网页应用程序。

DOM API 和 BOM API 都是由浏览器提供的 API，它们定义了浏览器中如何处理 HTML、XML 和其他文档，以及如何与浏览器窗口和浏览器对象进行交互。

JavaScript 语言作为浏览器脚本语言，也为 DOM API 和 BOM API 提供了实现和支持。开发人员可以使用 JavaScript 代码来操作 DOM 和 BOM，从而实现网页的交互和动态效果。

虽然 DOM API 和 BOM API 是由浏览器提供的，但 JavaScript 语言也可以为这些 API 提供更高级别的抽象和封装，以便开发人员更方便、更高效地使用这些 API。同时，JavaScript 语言也可以使用其他 API 来操作文档、窗口和其他浏览器对象，例如 HTML5 应用程序框架 (App Framework)。

让我来举一个例子来说明 DOM API 和 BOM API 是由浏览器提供的还是由 JavaScript 语言提供的。

假设我们要在网页中创建一个标签，可以使用 HTML 语言的 <tag> 元素，例如:

<tag>Hello World!</tag>

在这个例子中，我们使用 <tag> 元素来创建了一个标签，这个标签包含了一个文本节点。要创建这个标签，我们需要在 HTML 文档中使用 <tag> 元素。

但是，如果我们想要在 JavaScript 中创建这个标签，我们可以使用 DOM API 中的 createElement 方法。

例如:

const tagNode = document.createElement('tag');

在这个例子中，我们使用 createElement 方法在文档对象模型 (DOM) 中创建了一个名为 tag 的新标签节点。DOM API 提供了这个方法来创建新的元素节点，而这个节点可以包含文本、图像、链接等元素。

同样地，如果我们想要在 JavaScript 中创建浏览器窗口对象，我们可以使用 BOM API 中的 window.open 方法。例如:

const url = 'https://www.example'; const window = window.open(url);

在这个例子中，我们使用 window.open 方法创建了一个新窗口，这个窗口可以连接到 https://www.example 网址。BOM API 提供了这个方法来打开新窗口或切换现有窗口。

因此，虽然 DOM API 和 BOM API 都是由浏览器提供的，但 JavaScript 语言也为这些 API 提供了更高级别的抽象和封装，以便开发人员更方便、更高效地使用这些 API。

除了上述提到的 DOM 和 BOM API，还有一些重要的 API 不是由浏览器提供的。这些 API 是由操作系统或操作系统之上的更高级别抽象层提供的，它们可以让开发人员在桌面应用程序或移动应用程序中操作文件系统、访问摄像头、麦克风等硬件设备，以及进行系统级别的操作。

例如，Windows 操作系统提供了 API 来访问文件系统，Linux 操作系统也提供了类似的 API 来访问文件系统。这些 API 可以让开发人员编写桌面应用程序或移动应用程序，无需直接访问硬件设备或文件系统，而是通过更高级别的抽象层来实现。

此外，一些操作系统还提供了 API 来访问摄像头、麦克风等硬件设备，以及进行系统级别的操作，例如打开应用程序、关闭应用程序、调整音量等。

这些非浏览器提供的 API 可以让开发人员编写更加通用、灵活和可扩展的应用程序，同时也提高了应用程序与操作系统和其他硬件设备的交互能力。

...