TreeShaking vs 深度导入：两种导入方式的打包体积差异探究

先看你提到的两种接口导入写法：

// 方式一：直接导入具体文件
import { AnyInterface } from '@eng/lib/interfaces/AnyInterface';
// 方式二：从库入口导入
import { AnyInterface } from '@eng/lib';

打包体积是否存在差异？ #

多数情况下最终打包体积一致，但结果取决于库的构建配置和Tree Shaking的生效条件。

关于Tree Shaking的生效逻辑 #

你提到Webpack通过Tree Shaking移除未使用代码的思路是对的，但Tree Shaking生效需要满足几个前提：

• 库的代码必须采用ES模块（ESM）格式输出，不能是CommonJS（CJS）格式——CJS的动态特性会让Tree Shaking无法准确识别未使用代码。
• Webpack的mode需设置为production，此时默认开启Tree Shaking相关优化。
• 若导入的是TypeScript接口这类纯类型，情况更特殊：TypeScript在编译阶段会移除所有类型定义，不管哪种导入方式，最终打包产物里都不会包含接口的代码——因为接口只是编译时类型检查用的，运行时不存在。

两种导入方式的实际区别 #

• 方式一：直接定位到具体文件，导入范围更明确，即使Tree Shaking失效（比如库是CJS格式），也只会引入该文件的内容。
• 方式二：从库的入口文件导入，若库的入口做了export * from './interfaces/AnyInterface'这类导出，且库是ESM格式，Webpack的Tree Shaking会精准识别只用到AnyInterface，不会引入其他未使用的内容；但如果库的入口存在一些副作用代码（比如全局变量修改、立即执行的函数），这些副作用代码可能会被保留下来，导致打包体积略增。

总结 #

如果是TypeScript接口这类纯类型导入，两种方式最终打包体积完全一致——因为类型都会被编译移除。如果是导出的具名函数/类，只要库是ESM格式且Tree Shaking配置正确，两种方式的打包体积也会一致；只有当库的构建配置不规范（比如用CJS输出）或存在未标记的副作用时，方式二才可能导致体积变大。

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