JavaScript自执行匿名函数的作用？附Redis客户端初始化写法对比

先搞懂async版自执行匿名函数的作用 #

普通自执行匿名函数（IIFE）的核心是创建独立作用域，避免变量污染全局；而带async的自执行匿名函数，额外解决了在非async环境（比如全局代码、普通函数）里使用await语法的问题，同时还能保证内部的异步操作不会阻塞外部同步代码的执行。

两种写法的核心差异 #

1. 语法合法性 #

• 写法一：完全合法。自执行的async匿名函数提供了合法的async上下文，内部可以正常使用await redisClient.connect()，不会触发语法错误。
• 写法二：直接报错（除非满足特定条件）。await只能在async函数内部，或者ES模块的顶层作用域（需Node.js版本支持）中使用。如果这段代码写在普通全局作用域或非async函数里，会直接抛出SyntaxError: await is only valid in async functions and the top level bodies of modules。

2. 执行阻塞性 #

• 写法一：自执行async函数是异步执行的，内部的await只会阻塞函数内部的后续逻辑，不会影响外部同步代码。比如你的示例中，Express的app.listen可以在Redis连接完成前就启动，不会拖慢服务启动速度。
• 写法二：如果强行把这段代码放在支持await的上下文（比如async函数或ES模块顶层），await会阻塞当前上下文的所有后续代码，必须等Redis连接完成后才会继续执行，可能导致服务启动延迟。

3. 作用域隔离 #

• 写法一：自执行函数内部的临时变量（比如初始化时的配置变量）会被限制在函数作用域内，不会污染全局或外部作用域。
• 写法二：所有变量都处于当前作用域（比如全局），如果有临时变量会直接污染该作用域，增加变量冲突的风险。

总结 #

示例代码采用写法一，是因为在Express项目的全局代码场景下，这是最稳妥的方案：既解决了await的语法合法性问题，又能异步初始化Redis客户端，避免阻塞服务启动，同时还能隔离内部临时变量。

内容的提问来源于stack exchange，提问作者HubertBlu