1.写在前面本文旨在解释React异步请求内存泄漏问题的成因，并探究AbortController的使用。欢迎童鞋一起探讨交流。2.怎么会这样，why((灬??灬))经常用react开发项目的朋友应该经常遇到这种问题，就是一个弹框或者一个组件立马被另一个组件销毁，butitisdestroyedorclosed弹框里面可能有某种请求（请求的意思是：怪不得我，我还没回城，你拆了我的房子，呵呵~~)，此时组件被销毁，但是请求还在路上，请求的回调还没有释放，从而导致内存泄漏。3.AbortController应该怎么办？它是否即将被变量存储销毁？willUnmount时setState为真？为真时做一些操作？...好像不太行，怎么召回已经在路上的请求？类组件可以使用生命钩子，但是对于钩子，没有钩子。Fetch和axios似乎只返回承诺。当然rxjs可以（subscribe返回句柄，effect下可以返回unsubscribe），但是rxjs团队学习成本比较高，使用比较少。怎么做？AbortController对象实现了可以与请求通信的接口，通过它我们可以显式地中止请求。属性：AbortController.signal一个AbortSignal对象，我们可以持有它来与请求对话或中止它返回一个AbortSignal对象实例，可用于与DOM请求通信或中止。方法：请求中的AbortController.abort在DOM请求完成之前中止它。这能够中止获取请求、任何响应主体和流的消耗。使用（如何使用）哇，看起来还行！好像还可以，request销毁的时候也abort了，callback改变react的状态也abort了，不错。但是不知道有没有发现问题。每个请求都这样处理是不是太麻烦了？AbortController的信号是否可以控制多个请求，或者状态是否像承诺一样冻结？那么，我们来测试一下测试结果：AbortConntroller的abort和promise有同样的问题。一旦状态固化，使用这个实例信号的请求将直接拒绝优化。大家都用react开发项目，肯定是工程项目，不止一个地方用requests，逻辑一个一个写肯定不现实，但是AbortController单例模式设计显然不合适。axios在封装request方法时，使用工厂模式生成AbortController，封装一个hooks，或者给返回的promise添加属性，让用户拿到控制权。
