自我管理
在tcp/ip协议栈里，传输的数据基本上都是header+body的格式，但是tcp/ip因为是传输层的协议，他们不关心body数据是什么，只要把数据发送到对方就算任务结束了；而http协议不同，他是应用层的协议，数据到达之后工作只能说是完成了一半，还必须要告诉上层应用这是什么数据才行，否则上层应用也不知道这是什么数据，该如何处理。
早在http协议诞生之前就已经有了针对这种问题的解决方案，不过它是用在电子邮件系统里的，为的是可以让电子邮件发送ascii码以外的任意数据，方案的名字就叫做：多用途互联网邮件扩展！！！（熟悉不熟悉？大学课本里的），简称MIME.MIME是一个很大的标准规范，http只是取了其中的一部分，用来标记body的数据类型（你说巧不巧，就是这么巧mime的标准刚好合适http用）,这就是我们平常总能听到的MIME type.
MIME把数据分成了八大类，每个大类下再细分出多个子类，形式是type/subtype的字符串，又是这么巧，刚好也符合http明文的特点，所以能够很容易的纳入http头字段里。
但是仅仅有MIME type还不够，因为http在传输的过程中为了节约带宽，有时候会压缩数据，为了不要让浏览器继续’猜’,还需要有一个‘encoding type’告诉数据是什么编码格式，这样对方才能正确的解压缩，还原出原始的数据。
常见的Encoding type有三种
有了MIME type和Encoding type无论是浏览器还是服务器都可以轻松的识别出body的类型，也可以正确的处理数据了。
http协议为此定义了两个Accept请求头字段和两个Content实体头字段，用于客户端和服务器进行“内容协商”，也就是说，客户端用Accept头告诉服务器自己希望接收什么样的数据，而服务器用Content头来告诉客户端实际发送了什么样的数据。
Accept头字段标记的是客户端可以理解的MIME type可以用”,”做分割符列出多个类型，让服务器有选择的余地。
例如： Accept: text/html,application/xml,image/webp,image/png
相应的服务器会在响应报文里用头字段Content-Type告诉实体数据的真实类型：
Content-Type: text/html
Content-Type: image/png
这样浏览器看到报文里的类型是text/html,就知道是html文件，会调用排版引擎渲染出页面，看到image/png就知道这是一个png文件，就可以在页面显示图片。
Accept-Encoding字段标记的是客户端可以支持的压缩格式，同样可以用逗号分隔开，列出多个，服务器可以选择其中一种来压缩数据，实际使用的压缩格式放在响应头字段Content-Encoding里。
Accept-Encoding: gzip,defalte,br
Content-Encoding: gzip
不过这两个字段是可以省略的，如果请求报文里没有Accept-Encoding字段，就表示客户端不支持压缩数据；如果响应报文里没有Content-Encoding字段，就表示响应数据没有被压缩。
之前只是知道除了xhr之外新出了另一种很新的请求数据的方法叫做fetch它很不一样，包括创建请求的方式啊处理返回的数据啊返回的是一个promise啦之类的，之前只是粗略的知道一些，而不太清楚它到底是个什么东西，如此想来其实xhr我也一直都是习惯的在使用而已，貌似并没有从底层协议的角度去认识它到底是什么，正好最近做了一个RN的项目，其中的网络请求使用的都是fetch，最近又报了个http学习的课程，十几个课时下来我感觉自己对这些概念有了新的认识，记录如下。
通过对http协议的学习，我了解到它是我们网络生活中使用最广泛的网络传输协议位于应用层，依赖于下面的tcp/ip协议，网络协议的分层完美的实现了每一层只需要做好自己份内的事情就好了，不用关系下层是怎么实现的，也不需要知道自己的上层是如果工作的，http协议简单灵活易于扩展，本身并没有强制规定过多的条目，留给了大家很多的自由发挥的空间，所以啊，其实xhr也就是我们常用的ajax技术只是对http协议的一种实现。xhr对象提供了对http协议的完全的访问，包括作出post和head请求，以及普通的get请求的能力。长久以来前端一直使用它来创建网络的请求与后端通过开发协商好的接口来完成数据的获取工作，直到最近几年前端井喷式的发展新的es标准一个接一个的出台，各种异步api的登场promise\Generator\async一个比一个骚,也衍生出了fetch这样直接替代xhr来创建http请求的全新异步方式，它的promise风格更加适应当代的前端开发，所以如何理解fetch？为什么fetch发出的请求在控制台的network面板中你看不到？
答： fetch跟xhr平级，是对http协议的另一种实现方式，一种使用起来更加方便的网络请求数据的方式，既然它不是xhr所以在Chrome的开发面板的network下面的xhr下面自然就看不到了，因为确实没有xhr的网络请求。
html文件是一个http请求，html文件中的src是一个http请求，link是一个http请求，这些是浏览器读到相关的属性标签后主动发出的，而ajax是我们用js自己发出的，简单来说：fetch是http请求的另一种姿势。
浏览器要用http协议收发数据，首先要做的就是建立TCP链接。
依照TCP协议的规范，使用三次握手建立与web服务器的链接，对应到Wireshark里，就是最开始抓的三个包，
经过SYN SYN/ACK ACK的三个包之后，浏览器与服务器的TCP链接就建立起来了。
有了可靠的TCP链接通道后，HTTP协议就可以开始工作了。
http的工作模式是非常简单的，由于tcp/ip协议负责底层的具体传输工作，http协议基本上不用在这方面操心太多。那么http协议的核心部分是什么呢？答案就是它传输的报文内容。
http同tcp/ip协议类似，同样也需要在实际的传输的数据前附加一些头数据，不过与tcp/ip不同的是，它是一个纯文本的协议，所以头数据都是ASCII码的文本，可以很容易的用肉眼阅读，不用借助程序解析也能够看懂。
其中前两部分：起始行和头部字段经常合称为请求头或者响应头，消息正文又称为实体。
http协议规定报文必须有header,但是可以没有body，而且在header之后必须有一个‘空行’，也就是crlf.
不过好这个“大头”也不能太大，虽然http协议对header的大小没有限制，但是各个web服务器都不允许过大的请求头，因为头部太大可能会占用大量的服务器资源，影响运行效率。
http/1.1规定了8种请求方法，单词都必须是大写的形式。
请求方法只是一个指示，客户端并没有决定权，服务器掌控着所有的资源，有着绝对的决策权力。
在http协议里，所谓的安全是指请求方法不会破坏服务器上的资源，即不会对服务器上的资源造成实质的修改。
按照这个定义只有get/head方法是安全的，因为他们是只读操作。
所谓的幂等实际上是一个数学用语，意思是指多次执行同样的操作，结果也都是相同的，即多次幂后结果相等。很显然get和head既是安全的也是幂等的。按照RFC的语义：post是新增或者提交数据，多次提交数据会创建多个资源，所以不是幂等的
而put是替换或者更新数据，多次更新一个资源，资源还会是第一次更新的状态，所以是幂等的。
全球16亿个网站2亿多个域名，这个庞大的网络世界的底层机制就是http.
http/1.0并不是一个标准，只是记录已有实践和模式的一份参考文档，不具有实际的约束力，相当于一个备忘录。
“浏览器大战”再一次极大的推进力web的发展，http/1.0也在这个过程中经受了实践检验。于是在浏览器大战结束之后的1996年，http/1.1发布了RFC文档，编号为2616，正式开确立了延续十余年的传奇。
1.1的发布意味着今后互联网上所有的浏览器、服务器、网管、代理等只要用到http协议，就必须要严格遵守这个标准，相当于是互联网世界的一个立法。
谷歌不满足于http/1.1的性能，决定揭竿而起，开发了自己家的浏览器Chrome,然后推出了新的spdy协议，并在Chrome中应用于自家的服务器，用实际行动来倒逼http协议的变革，这也开启了第二次的浏览器大战。
历史再次重演，不过这次的胜利者是 Google，Chrome 目前的全球的占有率超过了 60%。“挟用户以号令天下”，Google 借此顺势把 SPDY 推上了标准的宝座，互联网标准化组织以 SPDY 为基础开始制定新版本的 HTTP 协议，最终在 2015 年发布了 HTTP/2，RFC 编号 7540。
虽然 HTTP/2 到今天已经四岁，也衍生出了 gRPC 等新协议，但是由于http/1.1实在是太过经典了和强势，目前http/2.0的普及率还比较低，大多数网站使用的仍然是20年前的http/1.1.
在 HTTP/2 还处于草案之时，Google 又发明了一个新的协议，叫做 QUIC，而且还是相同的“套路”，继续在 Chrome 和自家服务器里试验着“玩”，依托它的庞大用户量和数据量，持续地推动 QUIC 协议成为互联网上的“既成事实”。
首先，HTTP 是一个协议。
第一点，协议必须要有两个或多个参与者，也就是“协”。
第二点，协议是对参与者的一种行为约定和规范，也就是“议”。
协议意味着有多个参与者为了达成某个共同的目的而站在了一起，除了要无疑义地沟通交流之外，还必须明确地规定各方的“责、权、利”，约定该做什么不该做什么，先做什么后做什么，做错了怎么办，有没有补救措施等等。例如，“租房协议”里就约定了，租期多少个月，每月租金多少，押金是多少，水电费谁来付，违约应如何处理等等。
HTTP 是一个用在计算机世界里的协议。它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范，以及相关的各种控制和错误处理方式。
HTTP 是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。
所谓的“传输”（Transfer）其实很好理解，就是把一堆东西从 A 点搬到 B 点，或者从 B 点搬到 A 点，即“A<===>B”。
第一点，HTTP 协议是一个“双向协议“
文本（Text），就表示 HTTP 传输的不是 TCP/UDP 这些底层协议里被切分的杂乱无章的二进制包（datagram），而是完整的、有意义的数据，可以被浏览器、服务器这样的上层应用程序处理。
HTTP 是一个“传输协议“
在互联网早期，“文本”只是简单的字符文字，但发展到现在，“文本”的涵义已经被大大地扩展了，图片、音频、视频、甚至是压缩包，在 HTTP 眼里都可以算做是“文本”。
超文本，”，就是“超越了普通文本的文本”，它是文字、图片、音频和视频等的混合体，最关键的是含有“超链接”，能够从一个“超文本”跳跃到另一个“超文本”，形成复杂的非线性、网状的结构关系。
对于“超文本”，我们最熟悉的就应该是 HTML 了，它本身只是纯文字文件，但内部用很多标签定义了对图片、音频、视频等的链接，再经过浏览器的解释，呈现在我们面前的就是一个含有多种视听信息的页面。
HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。
实际的互联网是由许许多多个规模略小的网络链接而成的这些“小网络”可能是只有几百台电脑的局域网，可能是有几万、几十万台电脑的广域网，可能是用电缆、光纤构成的固定网络，也可能是用基站、热点构成的移动网络。。。
互联网世界更像是由数不清的大小岛屿组成的“千岛之国”
互联网的正式名称是Internet,里面存储着无穷无尽的信息资源，我们通常所说的“上网”实际上访问的只是互联网上的一个子集“万维网”，它是基于http协议，传输html等超文本资源，能力也就被限制在http协议之内。
互联网上还有许多万维网之外的资源，例如常用的电子邮件、BT和Magnet点对点下载、FTP文件下载、ssh安全登录、各种即时通信服务等等，他们需要各自的专有协议来访问。
由于http协议非常灵活、易于扩展，而且超文本的表述能力很强，所以很多其他原来不属于http的资源也可以“包装”成http来访问，这就是我们
为什么能够总看到各种“网页应用”—例如“微信网页版”“邮箱网页版”的原因。
综合起来看，现在的互联网90%以上的部分都被万维网，也就是http所覆盖，所以把互联网约等于万维网或者http应该也不算大错。
浏览器本质上是一个http协议中的请求方，使用http协议获取网络上的各种资源，当然，为了让我们更好的检索查看网页，它还集成了
很多额外的功能。
Web服务器是一个很大也很重要的概念，他是http协议里响应请求的主体，通常也把控着绝大多数的网络资源，在网络世界里处于强势地位。
当我们谈到web服务器的时候，有两个层面的概念：硬件和软件。
硬件含义就是物理形式或“云”形式的机器，在大多数情况下它可能不是一台服务器，而是利用反向代理、负载均衡等技术组成的庞大集群。但从外界看来，它仍然表现为一台机器，但这个形象是“虚拟的”。
软件含义的 Web 服务器可能我们更为关心，它就是提供 Web 服务的应用程序，通常会运行在硬件含义的服务器上。它利用强大的硬件能力响应海量的客户端 HTTP 请求，处理磁盘上的网页、图片等静态文件，或者把请求转发给后面的 Tomcat、Node.js 等业务应用，返回动态的信息。
现今有哪些web服务器？
内容分发网络，它应用里http协议里的缓存和代理技术，代替源站响应客户端的请求。
它可以缓存源站的数据，让浏览器的请求不用“千里迢迢”地到达源站服务器，直接在“半路”就可以获得响应。如果CDN的调度算法很优秀，更可以找到距离用户最近的节点，大幅度缩短响应的时间。打个比方，就好比唐僧西天取经，刚出长安城，就看到阿难与伽耶把佛祖的真经递过来了，是不是很省事！
实际上是一种可以自动访问Web资源的应用程序，据估计互联网上至少有50%的流量是由爬虫产生的。爬虫也有不好的一面：比如过度消耗网络资源，占用服务器和带宽，影响网站对真实数据的分析，甚至敏感信息的泄漏，所以又出现了翻爬虫技术，通过各种手段来限制爬虫，其中一项就是“君子协定”robots.txt,约定哪些该爬，哪些不该爬。
通过限定文件范围带来的性能提升是有限的。除此之外，如果我们选择开启缓存将转译结果缓存至文件系统，则至少可以将 babel-loader 的工作效率提升两倍。要做到这点，我们只需要为 loader 增加相应的参数设定：
loader: 'babel-loader?cacheDirectory=true'
DllPlugin 是基于 Windows 动态链接库（dll）的思想被创作出来的。这个插件会把第三方库单独打包到一个文件中，这个文件就是一个单纯的依赖库。这个依赖库不会跟着你的业务代码一起被重新打包，只有当依赖自身发生版本变化时才会重新打包。
用 DllPlugin 处理文件，要分两步走：
webpack 是单线程的，就算此刻存在多个任务，你也只能排队一个接一个地等待处理。
所谓按需加载，就是在正确的时机去触发相应的回调。
工具永远在迭代，唯有掌握核心思想，才能真正做到举一反三。
HTTP 压缩就是以缩小体积为目的，对 HTTP 内容进行重新编码的过程。
Gzip 的内核就是 Deflate，目前我们压缩文件用得最多的就是 Gzip。可以说，Gzip 就是 HTTP 压缩的经典例题。
如果你手上的项目是 1k、2k 的小文件，那确实有点高射炮打蚊子的意思，不值当。但更多的时候，我们处理的都是具备一定规模的项目文件。实践证明，这种情况下压缩和解压带来的时间开销相对于传输过程中节省下的时间开销来说，可以说是微不足道的。
首先要承认 Gzip 是高效的，压缩后通常能帮我们减少响应 70% 左右的大小。
但它并非万能。Gzip 并不保证针对每一个文件的压缩都会使其变小。
Gzip 压缩背后的原理，是在一个文本文件中找出一些重复出现的字符串、临时替换它们，从而使整个文件变小。根据这个原理，文件中代码的重复率越高，那么压缩的效率就越高，使用 Gzip 的收益也就越大。反之亦然。
一般来说，Gzip 压缩是服务器的活儿：服务器了解到我们这边有一个 Gzip 压缩的需求，它会启动自己的 CPU 去为我们完成这个任务。而压缩文件这个过程本身是需要耗费时间的，大家可以理解为我们以服务器压缩的时间开销和 CPU 开销（以及浏览器解析压缩文件的开销）为代价，省下了一些传输过程中的时间开销。
既然存在着这样的交换，那么就要求我们学会权衡。服务器的 CPU 性能不是无限的，如果存在大量的压缩需求，服务器也扛不住的。服务器一旦因此慢下来了，用户还是要等。Webpack 中 Gzip 压缩操作的存在，事实上就是为了在构建过程中去做一部分服务器的工作，为服务器分压。
图片是用户可以直观看到的。他们并不会关注 JS 和 CSS。
在页面加载的过程中，应当先让图片和文字先展示，而不是试图保证 JS 和 CSS 更快下载完成。
就图片这块来说，与其说我们是在做“优化”，不如说我们是在做“权衡”。因为我们要做的事情，就是去压缩图片的体积（或者一开始就选取体积较小的图片格式）。但这个优化操作，是以牺牲一部分成像质量为代价的。因此我们的主要任务，是尽可能地去寻求一个质量与性能之间的平衡点。
使用 JPG 呈现大图，既可以保住图片的质量，又不会带来令人头疼的图片体积，是当下比较推崇的一种方案。
JPG 的缺陷
有损压缩在上文所展示的轮播图上确实很难露出马脚，但当它处理矢量图形和 Logo 等线条感较强、颜色对比强烈的图像时，人为压缩导致的图片模糊会相当明显。
此外，JPEG 图像不支持透明度处理，透明图片需要召唤 PNG 来呈现。
如何确定一张图片是该用 PNG-8 还是 PNG-24 去呈现呢？好的做法是把图片先按照这两种格式分别输出，看 PNG-8 输出的结果是否会带来肉眼可见的质量损耗，并且确认这种损耗是否在我们（尤其是你的 UI 设计师）可接受的范围内，基于对比的结果去做判断。
应用场景
前面我们提到，复杂的、色彩层次丰富的图片，用 PNG 来处理的话，成本会比较高，我们一般会交给 JPG 去存储。
考虑到 PNG 在处理线条和颜色对比度方面的优势，我们主要用它来呈现小的 Logo、颜色简单且对比强烈的图片或背景等。
文本文件、依赖编码、 小图标解决方案
Base64 并非一种图片格式，而是一种编码方式。Base64 和雪碧图一样，是作为小图标解决方案而存在的。
图像精灵（sprite，意为精灵），被运用于众多使用大量小图标的网页应用之上。它可取图像的一部分来使用，使得使用一个图像文件替代多个小文件成为可能。相较于一个小图标一个图像文件，单独一张图片所需的 HTTP 请求更少，对内存和带宽更加友好。
Base64 是一种用于传输 8Bit 字节码的编码方式，通过对图片进行 Base64 编码，我们可以直接将编码结果写入 HTML 或者写入 CSS，从而减少 HTTP 请求的次数。
既然 Base64 这么棒，我们何不把大图也换成 Base64 呢？
这是因为，Base64 编码后，图片大小会膨胀为原文件的 4/3（这是由 Base64 的编码原理决定的）。
如果我们把大图也编码到 HTML 或 CSS 文件中，后者的体积会明显增加，即便我们减少了 HTTP 请求，也无法弥补这庞大的体积带来的性能开销，得不偿失。
在传输非常小的图片的时候，Base64 带来的文件体积膨胀、以及浏览器解析 Base64 的时间开销，与它节省掉的 HTTP 请求开销相比，可以忽略不计，这时候才能真正体现出它在性能方面的优势。
HTTP 缓存是最主要、最具有代表性的缓存策略，也是每一位前端工程师都应该深刻理解掌握的性能优化知识点，我们下面优先针对 HTTP 缓存机制进行剖析。
http缓存是最主要、最具有代表性的缓存策略，也是每一位前端工程师都应该深刻理解掌握的性能优化知识。
优先级较高的是强缓存，只有在强缓存命中失败的情况下才会走协商缓存。
expires的问题是对于本地时间的依赖，如果服务端和客户端的时间设置不同，或者我们直接手动把客户端的时间改掉，那么expires将无法正常工作。
考虑到 expires 的局限性，HTTP1.1 新增了 Cache-Control 字段来完成 expires 的任务。
expires 能做的事情，Cache-Control 都能做；expires 完成不了的事情，Cache-Control 也能做。因此，Cache-Control 可以视作是 expires 的完全替代方案。在当下的前端实践里，我们继续使用 expires 的唯一目的就是向下兼容。
在没有更好的本地存储解决方案的年代里，Cookie 小小的身体里承载了 4KB 内存所不能承受的压力。
为了弥补 Cookie 的局限性，让“专业的人做专业的事情”，Web Storage 出现了。
CDN的核心点有两个： 一个是缓存一个是回源。
这两个概念都非常好理解。对标到上面描述的过程，“缓存”就是说我们把资源 copy 一份到 CDN 服务器上这个过程，“回源”就是说 CDN 发现自己没有这个资源（一般是缓存的数据过期了），转头向根服务器（或者它的上层服务器）去要这个资源的过程。
同一个域名下的请求会不分青红皂白地携带 Cookie，而静态资源往往并不需要 Cookie 携带什么认证信息。把静态资源和主页面置于不同的域名下，完美地避免了不必要的 Cookie 的出现！
CSS 选择符是从右到左进行匹配的。
CSS性能提升的方法：
DocumentFragment 接口表示一个没有父级文件的最小文档对象。它被当做一个轻量版的 Document 使用，用于存储已排好版的或尚未打理好格式的XML片段。因为 DocumentFragment 不是真实 DOM 树的一部分，它的变化不会引起 DOM 树的重新渲染的操作（reflow），且不会导致性能等问题。
世间的事哪有什么对与错，我只是想守护我想守护的人而已。
对你的应用进行代码分割能够帮助你‘懒加载’当前用户所需要的内容，能够显著地提高你的应用性能。尽管懒加载并没有减少应用整体的代码体积，但是你可以避免加载用户永远不需要的代码，并在初始加载的时候，减少所需加载的代码量。
Context提供了一个不需要为每层组件手动添加props，就能在组件树之间进行数据传递的方法。
在一个典型的 React 应用中，数据是通过 props 属性自上而下（由父及子）进行传递的，但这种做法对于某些类型的属性而言是极其繁琐的（例如：地区偏好，UI 主题），这些属性是应用程序中许多组件都需要的。Context 提供了一种在组件之间共享此类值的方式，而不必显式地通过组件树的逐层传递 props。
Context 设计目的是为了共享那些对于一个组件树而言是“全局”的数据，例如当前认证的用户、主题或首选语言.
使用Context，我们可以避免通过中间元素传递props.
const ThemeContext = React.createContext('light');
class App extends React.Component {
render () {
return (
<ThemeContext.Provider value = 'dark'>
<Toolbalr />
</ThemeContext.Provider>
)
}
}
编写你自己的hooks
通过自定义hooks可以将组件逻辑提取到可重用的函数中。
自定义hooks是一种自然的遵循hooks设计的约定，而不是react的特性。
与class组件中的setState方法不同，useState不会自动合并更新对象。
惰性初始化state，initialState参数只会在组件的初始渲染中起作用，
后续渲染时会被忽略，如果初始化state需要通过复杂计算得到，可以传入一个
函数，在函数中计算并返回初始化的state,此函数只在初始化渲染时候被调用。
React使用Object.is比较算法来比较state.
在函数组件主体内（react渲染阶段），改变dom\添加订阅、设置定时器、记录日志以及执行其他
包含副作用的操作都是不被允许的，因为这可能会产生莫名其妙的bug并破坏ui的一致性。
使用 useEffect 完成副作用操作。赋值给 useEffect 的函数会在组件渲染到屏幕之后执行。你可以把 effect 看作从 React 的纯函数式世界通往命令式世界的逃生通道。
默认情况下，effect 将在每轮渲染结束后执行，但你可以选择让它 在只有某些值改变的时候 才执行。
要启用hook，所有react相关的package都必须要升级到16.8.0或者更高版本，如果你忘记更新诸如ReacctDOM之类的package,hook将会无法运行。
RN 会在它的下一个稳定版本中全面支持hook
长远来看，我们期望 Hook 能够成为人们编写 React 组件的主要方式
我们给 Hook 设定的目标是尽早覆盖 class 的所有使用场景。目前暂时还没有对应不常用的 getSnapshotBeforeUpdate 和 componentDidCatch 生命周期的 Hook 等价写法，但我们计划尽早把它们加进来。
最新版的 Flow 和 TypeScript React 定义已经包含了对 React Hook 的支持。
重要的是，在你需要严格限制类型的时候，自定义 Hook 能够帮你限制 React 的 API。React 只是给你提供了基础功能，具体怎么用就是你自己的事了。
effect hook 可以让你在函数组件中执行副作用操作。
将document的title设置为包含了点击次数的消息。
数据获取，设置订阅以及手动更改react组件中的dom都属于副作用。
可以把useEffect hook看作是 componentDidMount componentDidUpdate 和 componentWillUnmount三个
函数的组合。
在React中有两种常见的副作用操作：需要清除的和不需要清除的。
无需清除的副作用
有时候，我们只想在 React 更新 DOM 之后运行一些额外的代码。比如发送网络请求，手动变更 DOM，记录日志，这些都是常见的无需清除的操作。因为我们在执行完这些操作之后，就可以忽略他们了。让我们对比一下使用 class 和 Hook 都是怎么实现这些副作用的。
使用class的例子
记住： 在class组件中，render函数是不应该有任何副作用的，一般来说，在这里执行操作太早了，我们基本都希望
在React更新dom之后才执行我们的操作。
这就是为什么在Reactclass中，我们把副作用操作放到componentDidMount和componentDidUpdate函数中。
class Example extends React.Component {
constructor(props) {
super(props);
this.state = {
count: 0
};
}
componentDidMount() {
document.title = You clicked ${this.state.count} times;
}
componentDidUpdate() {
document.title = You clicked ${this.state.count} times;
}
render() {
return (
You clicked {this.state.count} times
注意，在这个class中，我们需要在两个生命周期函数中编写重复的代码。
这是因为在很多情况下，我们希望在组件加载和更新操作的时候执行同样的操作，从概念上说我们希望它在每次
渲染之后执行—但是react的class组件没有提供这样的方法，即使我们提取出这样一个方法，我们还是要在两个地方调用它。
useEffect版本
import React, { useState, useEffect } from ‘react’;
function Example() {
const [count, setCount] = useState(0);
useEffect(() => {
document.title = You clicked ${count} times;
});
return (
You clicked {count} times
useEffect做了什么？ 通过这个hook，你可以告诉react组件需要在渲染后执行某些操作。react会保存你传递的函数
我们称之为effect,并且在执行dom更新之后调用它。在这个effect中，我们设置了document的title属性，
不过我们也可以执行数据获取或者调用其他命令式的api.
为什么在组件内部调用useEffect?
将useEffect放在组件内部让我们可以在effect中直接访问count state变量，我们不需要特殊的api机制来读取它。
它已经保存在函数的作用域中了。hoook使用了js的闭包机制，而不用在js已经提供了解决方案的情况下，还引入特性的
react api.
useEffect会在每次渲染后都执行吗？是的，默认情况下，它在第一次渲染后和每次更新之后都会执行。
react保证了每次运行effect的时候，dom都已经更新完毕。
每次我们重新渲染，都会生成一个新的effect，替换掉之前的，某种意义上说effect更像是渲染结果的一部分—每个
effect属于一次特定的渲染。
与 componentDidMount 或 componentDidUpdate 不同，使用 useEffect 调度的 effect 不会阻塞浏览器更新屏幕，这让你的应用看起来响应更快。大多数情况下，effect 不需要同步地执行。在个别情况下（例如测量布局），有单独的 useLayoutEffect Hook 供你使用，其 API 与 useEffect 相同。
以上是不需要清除的effect
需要清除effect的情况
有一些副作用是需要清除的，例如订阅了外部的数据源，这种情况下清除工作是非常重要的，可以防止
引起内存泄漏！
componentDidMount 和 componentWillUnmount之间相互对应。使用生命周期函数迫使我们
拆分这些逻辑代码，即使这两部分代码都作用于相同的副作用。
使用hook
你可能认为需要单独的effect来执行清除操作。但是由于添加和删除订阅的代码的紧密性，所以
useEffect的设计是在同一个地方执行。如果你的的effect返回一个函数，React将会在执行清除操作时调用它。
为什么要在effect中返回一个函数呢？这是effect可选的清除机制。每个effect都可以返回一个函数。
hook的设计可以帮助我们创建bug更少的组件。
忘记正确的处理componentDidUpdate是React中常见的bug来源。
useEffect会在调用下一个新的effect之前对前一个effect进行清理。
如果某些特定值在两次渲染之间没有发生变化，你可以通知react跳过对effect的调用，只要传递
数组作为useEffect的第二个参数即可。
useEffect(() => {
document.title = you clicked ${count} times;
}, [count]); // 仅仅在count变化的时候更新
上面这个示例中，我们传入 [count] 作为第二个参数。这个参数是什么作用呢？如果 count 的值是 5，而且我们的组件重渲染的时候 count 还是等于 5，React 将对前一次渲染的 [5] 和后一次渲染的 [5] 进行比较。因为数组中的所有元素都是相等的(5 === 5)，React 会跳过这个 effect，这就实现了性能的优化。
当渲染时，如果 count 的值更新成了 6，React 将会把前一次渲染时的数组 [5] 和这次渲染的数组 [6] 中的元素进行对比。这次因为 5 !== 6，React 就会再次调用 effect。如果数组中有多个元素，即使只有一个元素发生变化，React 也会执行 effect
未来的版本可能在构建时候自动添加第二个参数。
注意如果你要使用此优化方式，请确保数组中包含了所有外部作用域中会随时间变化并且在effect中使用
的变量。
如果想执行只运行一次的effect，可以传递一个空数组作为第二个参数。这就告诉react你的
effect不依赖于任何props和state中的任何值。所以它永远都不需要重复执行。
我们推荐启用 eslint-plugin-react-hooks 中的 exhaustive-deps 规则。此规则会在添加错误依赖时发出警告并给出修复建议。
推荐使用eslint-plugin-react-hooks中的exhaustive-deps规则，此规则会在
添加错误的依赖时发出警告并给出修复的建议。
state hook 和 effect hook 涵盖了大多数的使用class的用例。
import React, {useState, useEffect} from 'react';
function Example() {
const [count, setCount] = useState(0);
useEffect(() => {
document.title = `you clicked ${count} times`;
})
return (
<div>
<p>you clicked {count} tiems</p>
<button onClick={() => setCount(count + 1)}>Click me</button>
</div>
)
}