IIFE 会破坏 Tree Shaking，因其将静态 ES 模块导出包裹进动态作用域，使打包工具无法识别真实引用；需通过现代编译目标、剥离副作用逻辑及验证产物等方式规避。
自执行函数（IIFE）会破坏 Tree Shaking，因为它把原本静态可分析的 ES 模块导出包裹进动态作用域，导致打包工具无法识别哪些导出被真正引用。关键不是“禁用 IIFE”，而是避免它在模块顶层、导出前或装饰器编译过程中意外生成。
识别 IIFE 是怎么悄悄出现的
很多情况下你没手写 IIFE，但它由工具链自动注入：
- TypeScript 设置 target: "es5" 时，类和装饰器会被编译成带 IIFE 的代码，例如：
(function() { class A {} exports.A = A; })()—— 整个模块变成黑盒，Tree Shaking 失效 - Babel 启用了
@babel/plugin-transform-classes或旧版装饰器插件（如@babel/plugin-proposal-decorators+legacy: true），也会包裹类声明 - 某些 polyfill 或兼容性脚本（如 core-js）通过 IIFE 注入全局逻辑，若放在工具模块中，会污染 sideEffects 判断
用现代编译目标切断 IIFE 生成
让源码保持原始 ESM 结构，是 Tree Shaking 起效的基础：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- TypeScript 中设 "target": "es2022" 或更高，并启用 "useDefineForClassFields": true，避免 class 被降级为 IIFE 包裹
- Babel 配置中移除
loose: true，禁用@babel/plugin-transform-modules-commonjs（防止 ESM → CJS → 再转回 IIFE） - 确认构建产物里没有类似
(function(){...})()包裹导出语句；可用rollup -c --silent | head -n 20快速检查入口输出
把副作用逻辑从导出模块中剥离
IIFE 常用来“安全执行初始化”，但它的存在本身就会阻断静态分析。替代方案更干净：
立即学习“Java免费学习笔记（深入）”；
- 把注册、挂载、polyfill 等操作移到 入口文件（如 main.js）或专用初始化模块，主业务模块只保留
export const fn = ...这类纯声明 - 如果必须在类定义时触发逻辑（如
@customElement），改用运行时注册：导出裸类export class MyButton {}，再在入口调用customElements.define('my-button', MyButton) - 对已有 IIFE 封装的第三方库，优先选 ESM 原生版本（如
lit替代老版polymer），或通过sideEffects精确标记其副作用文件，不波及其他模块
验证 IIFE 是否已清除
别只看配置，直接查产物：
- 构建后打开 bundle 文件，搜索
function(或(function，确认核心工具模块（如utils.js）没有被包裹 - 用
rollup-plugin-visualizer或source-map-explorer查看模块是否被整块引入——若一个只用了一个函数的工具模块显示“100% used”，大概率被 IIFE 锁死了 - 在源码中加
/*#__PURE__*/标记无副作用调用（如/*#__PURE__*/initLib()），配合treeshake: { moduleSideEffects: false }进一步收紧判断
