设计闭包（Closure）的初衷是为了解决什么问题？
在解决异步编程的内存管理问题上十分有意义。 只要我们目前使用的计算机硬件架构没有翻天覆地的改变，那么内存管理方案始终是绕不开围绕着作用域的，比如C++的RAII以及其延伸出的引用计数，所有权等。因为作用域非常适合强上下文关联的逻辑。但异步编程的问题就在于，它不按套路出牌，不是按照指令式编程的上下文关系来执行，而是东一榔头西一棒槌，这就导致内存管理的难度大幅度上升。 那解决方案基本分两类，要么干脆放弃内存管理，高高的举起自己的小白旗并把生杀大权交给GC，这种自然不在讨论范围内，另一种方案就是让异步事件保留自己需要用到的资源的生命周期所有权或知情权。所有权意味着当这个对象在事件还没执行完毕前必然不能销毁，而知情权则意味着事件执行时如果对象已经被干掉，那么事件内的逻辑能够及时知道，这整个过程都是围绕着闭包来操作的。 先前有幸接触过一些C++开发的异步网络业务逻辑代码和框架，里面对于异步内存管理的控制程度堪称精妙，乍一看满屏手动闭包，代码“又臭又长”，当时感到难以理解，但与架构设计师聊过以后才发现，这种设计既不是语言的乏力，也不是框架的无能，它恰恰是人类绞尽脑汁与计算机逻辑博弈和厮杀后，留下的血淋淋的战果。