Tree Shaking 是什么？为什么没用到的代码仍然进了包？

知识点详解：没用到的导出，为什么不一定能直接删

导出没有使用，不等于模块没有事情要做

假设工具库提供日期格式化和图表组件，你只用了日期格式化。删除未用的图表代码，可能减少构建体积。

但这个库入口还执行了主题注册。如果注册行为会影响正在使用的组件，删除入口执行就改变了程序。

这里有两种问题：某个导出是否需要，整个模块是否必须执行。工具会分析代码，也需要可信的副作用信息；无法证明安全时，保留代码不一定是工具失效。

静态结构好分析，动态行为需要更多条件

ESM 的 import、export 让依赖和导出关系在构建时更容易确定。CommonJS 则允许更动态地改变导出，不同工具对它的分析能力也不同。

不过，保留 ESM 只是有利条件。模块顶层调用、动态访问导出、转换流程和压缩器能力，都会影响最终结果。

“源码使用了 import”也不代表到打包阶段仍然保留 ESM。如果前面的转译已经改成 CommonJS，就要根据最终进入打包器的形式判断。

本题是 JavaScript 模块构建机制，Python 的未使用 import 检查不是等价 Tree Shaking 实现。

sideEffects 是承诺，不能随手填

Webpack 中，sideEffects 声明可以让工具跳过无需保留的模块及其依赖。它和 usedExports 对导出使用情况的分析不是完全同一件事。

如果包确实存在样式导入，可以按真实路径把 CSS 列为有副作用。插件注册、polyfill 和全局监听也需要检查。

不是把所有文件都标成有副作用才安全，而是准确写出哪些初始化必须保留。反过来，随手写 false 会让工具相信“删除这些模块执行不会改变行为”。

这里的声明属于构建元数据，不能靠运行时 try/catch 把已经被删除的初始化找回来。

验证时，挑最小使用场景看产物

先建一个只使用目标导出的最小入口，执行生产构建，检查无关代码是否仍在产物里。再打开页面，确认 CSS、组件注册和必要初始化没有丢。

如果没有删掉，可以沿着导入链检查：是否引入了预打包文件、是否提前转为 CommonJS、是否存在顶层副作用、声明有没有匹配实际路径。

代码压缩、代码分割和 Tree Shaking 也不是一回事。压缩可以缩短名字；分割可以推迟下载；Tree Shaking 尝试删除不需要的代码。三者可以一起使用，但不能互相证明已经生效。

本题机制参考：Webpack：Tree Shaking、Webpack：Concepts。

面试官继续追问

ESM 一定能被完整 Tree Shake 吗？

不一定。静态模块结构有利于分析，副作用、转译和工具能力仍然决定可以安全删除多少。

sideEffects: false 是关闭所有副作用吗？

不是。它只是声明模块执行可被安全跳过；不会在运行时阻止副作用，也不会自动验证声明正确。

打包文件变小，就证明 Tree Shaking 起作用了？

可能来自压缩、分块或依赖变化。需要检查实际产物和使用入口，区分原因。

面试速记卡

• 目标：删除可以安全移除的代码，不是只看调用次数。
• ESM：静态结构有利于分析，不保证完全删除。
• 副作用：初始化、注册、polyfill、CSS 都要检查。
• sideEffects：声明责任在作者，错误声明可能删掉必要行为。
• 验收：生产产物与最小页面行为一起看。