不当使用 iife 或闭包会破坏 es 模块静态结构，导致 tree shaking 失效；核心在于掩盖真实依赖与副作用，使构建工具无法准确分析导出引用关系。
不当使用 IIFE 或闭包会破坏 ES 模块的静态结构，使构建工具无法准确分析导出与引用关系，从而让 Tree Shaking 失效。核心问题不在“用了闭包”，而在于它掩盖了模块的真实依赖和副作用行为。
IIFE 直接阻断模块静态分析
Tree Shaking 依赖 ES Module 的静态 import/export 语法做编译期分析。IIFE 是运行时执行的函数表达式，完全脱离模块系统：
- Webpack、Rollup 等工具根本“看不到” IIFE 内部定义了什么变量或函数，也无法判断哪些导出被外部用到
- 即使你把 IIFE 包裹的代码写成
export const utils = {...}，只要外层套了(function(){...})()，ESM 解析就中断了 - 常见误用：将整个 CommonJS 风格模块（含 require）塞进 IIFE，再试图用 Webpack 打包——此时连基本的 import 都无法识别，更别说摇树
闭包隐式创建全局或顶层副作用
闭包本身不阻碍 Tree Shaking，但若在模块顶层或导出前通过闭包触发副作用，就会让整个文件被保留：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 例如：
const init = (() => { console.log('loaded'); return () => {}; })(); export { init };—— 顶层立即执行，产生副作用，Webpack 认为该模块“有 sideEffects”，不会删除它 - 又如：闭包内修改
window、监听document、调用fetch，哪怕只执行一次，也会污染模块纯净性 - 关键点：Tree Shaking 要求模块是“纯”的（pure module），即无顶层副作用；闭包若在定义时就执行并产生副作用，等于把副作用提前固化在模块加载阶段
私有变量/函数被闭包捕获后无法被识别为未使用
当本可被摇掉的内部逻辑被闭包“锁住”，工具就无法判定其是否真正被消费：
- 比如：
export function createApi() { const baseUrl = 'https://api.example.com'; return { get: () => fetch(baseUrl) }; }—— 这里baseUrl是闭包变量，虽未直接导出，但因被返回对象的方法引用，构建工具保守起见会保留整块逻辑 - 更隐蔽的是：闭包中引用了某个大型工具函数，而该函数本身没被其他地方 import，理论上可删；但由于闭包持有引用，它就被“意外保留”
- 这不是 bug，而是静态分析的局限：工具无法 100% 推断闭包内所有可能的执行路径，所以倾向于保留而非冒险删除
修复方向：用 ESM 替代 IIFE，把副作用显式封装
不是禁用闭包，而是让它服务于模块规范：
- 把 IIFE 拆成标准
export函数，用import显式声明依赖 - 将副作用逻辑（如 DOM 初始化、事件绑定）移到单独函数中，用
/*#__PURE__*/标记调用，并确保该文件在package.json的"sideEffects"列表里 - 避免在模块顶层执行任何操作；所有初始化都延迟到函数调用时，保持模块“惰性”和“纯净”
