IIFE中如何使用闭包技巧

在文章实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《IIFE中如何应用JavaScript闭包》，聊聊，希望可以帮助到正在努力赚钱的你。

IIFE与闭包结合的核心是创建私有作用域并封装数据，通过闭包访问IIFE内部变量实现模块化；2. 这种模式避免全局污染、实现数据封装和明确依赖，曾是JavaScript模块化的标准方案；3. 常见陷阱包括循环中var变量共享导致的闭包问题，可用IIFE为每次循环创建独立作用域解决；4. 需注意闭包可能引发内存泄漏，因外部变量无法被及时回收；5. 尽管ES Modules已成主流，IIFE与闭包仍在旧项目维护、脚本封装、库打包及理解底层机制中具有重要价值。

在JavaScript中，当闭包与立即执行函数表达式（IIFE）结合时，我们实际上是在利用IIFE创造一个独立的作用域，而闭包则利用这个作用域来“记住”并访问其中的变量，即使IIFE本身已经执行完毕。这就像是IIFE搭了一个临时的舞台，表演结束后，舞台拆了，但演员（闭包）却把舞台上的道具（变量）带走了，以后还能用。核心思想就是：创建私有状态和数据封装。

解决方案

IIFE（Immediately Invoked Function Expression）本质上是一个函数定义后立即执行的表达式。它的主要作用是创建私有作用域，避免变量污染全局命名空间。而闭包，简单来说，就是一个函数能够记住并访问其“出生地”（定义时的词法作用域）的变量，即使它在其他地方被执行。

当这两者结合时，IIFE提供了一个临时的、私有的执行环境。在这个环境中定义的变量和函数，默认是外部无法直接访问的。但如果IIFE内部返回了一个函数，并且这个返回的函数引用了IIFE内部的变量，那么这个返回的函数就形成了一个闭包。它“封闭”了IIFE内部的某些状态，使得这些状态在IIFE执行完毕后依然能够被访问和操作。

一个非常经典的例子就是模块模式。我们用IIFE来封装模块的所有内部逻辑和数据，然后只通过返回一个对象来暴露公共接口。这些公共接口的方法就是闭包，它们可以访问并操作IIFE内部的私有变量。

var myModule = (function() {
    var privateVariable = '我是私有的数据'; // IIFE内部的私有变量
    var counter = 0;

    function privateMethod() {
        console.log('这是私有方法，外部看不到我。');
    }

    function incrementCounter() {
        counter++;
        console.log('计数器：', counter);
    }

    function getPrivateVariable() {
        return privateVariable;
    }

    // 返回一个对象，暴露公共接口
    return {
        publicMethod: function() {
            console.log('我是公共方法，我可以访问私有数据：' + privateVariable);
            privateMethod(); // 也可以调用私有方法
        },
        getCounter: function() {
            return counter;
        },
        addOne: incrementCounter // 暴露一个可以操作私有变量的方法
    };
})(); // IIFE立即执行

myModule.publicMethod(); // 输出：我是公共方法，我可以访问私有数据：我是私有的数据 / 这是私有方法，外部看不到我。
myModule.addOne();      // 输出：计数器： 1
myModule.addOne();      // 输出：计数器： 2
console.log(myModule.getCounter()); // 输出：2

// 尝试访问私有变量或方法会报错或得到undefined
// console.log(myModule.privateVariable); // undefined
// myModule.privateMethod(); // 报错

在这个例子里，privateVariable、counter和privateMethod都只存在于IIFE的作用域内。myModule对象中返回的publicMethod、getCounter和addOne，它们都是闭包，因为它们都“记住”了IIFE的作用域，并能够访问和修改其中的变量。这样就实现了数据封装和信息隐藏，外部只能通过我们暴露的接口来与模块交互。

为什么在JavaScript模块化开发中，IIFE与闭包的结合如此常见？

说实话，这种模式在ES Modules（import/export）出现之前，几乎是JavaScript模块化开发的“黄金标准”。它解决了一个非常核心的问题：全局变量污染。在Web应用的早期，所有的JavaScript代码都共享一个全局作用域。如果两个不同的脚本都定义了同名的变量或函数，就会发生冲突，覆盖彼此的功能，这简直是灾难。

IIFE就像一个独立的“沙盒”，它在自己的小世界里运行代码，这个小世界里的变量和函数不会泄露到外面去。但我们又不能完全隔离，总得有个办法让外部能用上沙盒里的一些功能吧？这时候，闭包就派上用场了。通过IIFE返回一个包含公共方法的对象，这些方法作为闭包，能够安全地访问并操作IIFE内部的私有状态。

这种结合带来的好处是显而易见的：

• 避免命名冲突： 每个模块都有自己的私有作用域，内部变量不会污染全局。
• 数据封装： 模块的内部实现细节（私有变量、私有方法）对外是不可见的，只能通过暴露的公共API来访问，这大大提升了代码的可维护性和安全性。
• 明确的依赖关系： 虽然不如ES Modules那样显式，但通过参数传入依赖（例如jQuery），也能在一定程度上管理依赖。

所以，在那个没有原生模块系统的时代，IIFE与闭包的组合提供了一种非常优雅且实用的方式来构建大型、可维护的JavaScript应用，它奠定了现代前端工程化的一些基础。

使用IIFE和闭包时，有哪些常见的陷阱或需要注意的地方？

尽管IIFE和闭包非常强大，但在使用时确实有一些坑需要注意，尤其对于初学者来说，一不小心可能就掉进去了。

一个比较经典的“坑”就是循环中的变量捕获问题。这通常发生在var声明的变量上。因为var没有块级作用域，只有函数作用域，所以当你在一个循环里创建多个闭包（比如给多个DOM元素添加事件监听器）时，它们会共享同一个外部变量。

// 常见的陷阱示例
for (var i = 0; i < 3; i++) {
    setTimeout(function() {
        console.log(i); // 每次都输出 3
    }, 100);
}
// 为什么会这样？因为当 setTimeout 回调执行时，循环早已结束，i 的值已经是 3 了。
// 所有的闭包都引用了同一个 i。

解决这个问题，IIFE就派上用场了。通过在每次循环中立即执行一个函数，并把当前的i值作为参数传进去，就可以为每个闭包创建一个独立的i副本：

// 使用 IIFE 解决循环变量问题
for (var i = 0; i < 3; i++) {
    (function(index) { // IIFE 立即执行，并接收 i 作为参数 index
        setTimeout(function() {
            console.log(index); // 每次输出 0, 1, 2
        }, 100);
    })(i); // 将当前的 i 值传入 IIFE
}

另一个需要注意的点是内存管理。闭包会保留对其词法环境的引用。如果这个词法环境非常大，或者闭包本身被长期持有（比如作为事件监听器但没有被移除），那么它所引用的外部变量可能就无法被垃圾回收，从而导致内存泄漏。虽然现代JavaScript引擎在这方面做了很多优化，但了解这个机制仍然很重要，尤其是在处理大量数据或长时间运行的应用程序时。

还有就是this的上下文问题。在闭包内部，this的指向会变得复杂，它不总是指向你期望的对象。这通常需要显式地绑定this（比如使用bind方法，或者在外部作用域保存this到var self = this）。不过，箭头函数在很大程度上解决了这个问题，因为它们没有自己的this，会捕获其父作用域的this。

IIFE和闭包的组合，在现代JavaScript开发中是否还有其一席之地？

这是一个非常好的问题。随着ES Modules（ESM）的普及，以及像Webpack、Rollup这类打包工具的广泛应用，我们现在有了更原生、更声明式的模块化方案。import和export语法让模块间的依赖关系一目了然，也提供了静态分析的可能。从表面上看，IIFE和闭包的模块模式似乎已经“过时”了。

然而，我个人觉得，说它完全没有一席之地，那可能有点武断。它们仍然在某些场景下发挥着作用，或者说，理解它们的工作原理，对于深入理解JavaScript的运行时机制至关重要。

• 旧项目维护： 大量现存的JavaScript代码库，尤其是一些老的库和框架，仍然广泛使用IIFE模块模式。如果你需要维护或扩展这些项目，理解这种模式是基础。
• 脚本标签中的封装： 在一些不需要或无法使用模块打包工具的简单网页中，或者当你只是想在HTML中直接引入一个小的、自包含的脚本时，IIFE仍然是避免全局变量污染的最佳实践。它能确保你的脚本不会意外地干扰页面上其他脚本的行为。
• 库和插件的包装： 许多JavaScript库在发布时，为了兼容各种环境（包括那些不支持ESM的环境），仍然会使用IIFE将整个库封装起来，以确保其内部变量的私有性。例如，jQuery的经典包装方式就是IIFE。
• 理解底层机制： 即使你日常开发都用ESM，理解IIFE和闭包如何实现作用域隔离和数据封装，能帮助你更好地理解ESM在底层是如何工作的。ESM本质上也是一种更高级、更规范的“闭包”和“作用域”管理机制。它只是把这些复杂的概念用更简洁的语法抽象出来了。

所以，与其说IIFE和闭包的组合“过时了”，不如说它已经从主流的模块化解决方案，退居为一种特定场景下的实用工具，以及一个理解JavaScript核心概念的重要基石。就像你可能不再用手动挡汽车去跑长途，但学习手动挡能让你更懂汽车的原理一样。

今天关于《IIFE中如何使用闭包技巧》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！