在现代前端构建中，依赖图膨胀与 tree-shaking 失效已成为影响 bundle 性能的核心挑战。当开发者使用npm install拉取一个看似简单的工具库时，实际引入的可能是数百个深层依赖。这些依赖带来的不仅是 bundle 体积膨胀，还有解析时间延长、供应链安全风险增加等一系列工程问题。本文基于 e18e 社区对 JavaScript 生态的长期观察，分析依赖膨胀的三大根源，并给出可量化的优化阈值与实践路径。

依赖膨胀的三大根源

依赖图膨胀并非单一因素造成，而是 JavaScript 生态演进过程中多种设计理念交织的结果。理解这些根源是解决问题的第一步。

第一根源于过时的运行时兼容性需求。 许多看似基础的工具库实际上携带了大量用于兼容古老运行时的代码。以is-string为例，这个仅用于判断字符串类型的小工具，其依赖图包含了hasown、math-intrinsics等深层包。造成这一现象的原因主要有三点：支持 ES3 级别的古老引擎如 IE6/7、保护全局命名空间被意外修改的 “防御性编程”、以及跨 realm 值传递的场景如 iframe 通信。这些需求在今天的常青浏览器和现代 Node.js 环境中已基本不存在，但其代码却随着每个依赖包进入了数以百万计项目的构建产物。ES5 早在 2009 年就已发布，ES6 更是 2015 年的产物，大多数项目完全不需要这些兼容性层级。

第二根源于原子级依赖架构的过度实践。 模块化设计的初衷是好的 —— 将代码拆分为可复用的微小单元，不同项目可以共享这些单元从而避免重复造轮子。然而当这种理念走向极端时，情况变得荒谬起来。shebang-regex这样一个仅包含一行正则表达式的包被独立发布；arrify这样一个将值转换为数组的函数成为独立 npm 包；path-key这样一个简单的环境变量键名获取逻辑也被拆分成单独项目。这些原子包的典型特征是几乎只有一个消费者 —— 它们往往由同一维护者创建，仅被其另一个项目使用。这种过度拆分非但没有带来预期的复用收益，反而增加了版本解析成本、依赖冲突风险和供应链攻击面。更关键的是，当这些原子包被 dupplicate（同一包的不同版本同时存在于依赖树中）时，tree-shaking 往往无法有效识别和消除这些冗余。

第三根源于 “ponyfill” 的过度使用与维护滞后。 Ponyfill 是一种不污染全局环境的 polyfill 替代方案，库作者可以借此使用尚未被所有引擎支持的未来特性，同时不影响消费者环境。理论上，当这些特性被广泛支持后，ponyfill 应当被移除。然而实际情况是，大量 ponyfill 在目标特性已完全支持后仍然被保留。globalthis这个 ponyfill 每周仍有 49M 下载量，但globalThis在 2019 年就已获得广泛支持；indexof每周 2.3M 下载，但Array.prototype.indexOf在 2010 年就已是标准；object.entries每周 35M 下载，但Object.entries在 2017 年就已普遍支持。这些过时的 ponyfill 不仅增加了 bundle 体积，还带来了潜在的安全风险和维护负担。

Tree-shaking 失效的技术机制

理解了依赖膨胀的根源后，需要进一步理解为什么 tree-shaking 在应对这些膨胀时常常失效。Tree-shaking 依赖静态代码分析来识别未使用的导出，其有效运行需要满足几个前提条件：代码必须使用 ES 模块语法、依赖必须是可分析的、导出必须是真正的 “死代码”。然而在现实场景中，这些前提经常被破坏。

动态导入如import(variable)使静态分析无法确定哪些模块将被使用，导致整个依赖树被保留。条件性导出会产生类似的保守估计结果。更隐蔽的问题是 CommonJS 与 ES 模块的混合使用 —— 当一个 ES 模块依赖 CommonJS 包时，tree-shaking 器往往无法分析该包的实际使用情况，整个模块会被保留。即使对于纯 ES 模块，某些复杂的代理对象和 Proxy 包装也会干扰静态分析。在原子级依赖架构中，大量微小模块的嵌套依赖使得分析深度急剧增加，分析器可能在达到一定深度后放弃精确分析，转而采取保守策略。

更根本的问题在于依赖本身的 “不可摇” 特性。许多传统库使用 IIFE 或 UMD 打包模式输出，这些模式本质上与 tree-shaking 不兼容。某些库虽然支持 ES 模块导出，但其内部实现可能是基于 CommonJS 编写的，只是通过编译转换层伪装成 ES 模块。最棘手的情况是那些 “副作用” 代码 —— 模块级别的console.log、全局状态修改、或带有side effect标记的导入，即使从未被显式调用，也会阻止整个模块被消除。

可量化的优化阈值与监控指标

基于行业实践与 e18e 社区的经验，可以建立一套量化的依赖管理阈值。这套阈值并非绝对标准，而是提供了可参考的基准线，帮助团队识别需要关注的问题。

直接依赖数量是首要监控指标。一个健康的中大型项目，其直接依赖应当控制在 50 个以内。如果超过 100 个，说明依赖管理可能存在过度问题。传递依赖（即直接依赖的依赖）的数量应当保持在 500 以下，可以通过npm ls --depth=5命令进行审计。

对于 bundle 体积，单个 JavaScript 文件建议不超过 500KB gzip 后的体积。实际上，对于首屏加载关键的路径，压缩后应控制在 100KB 以内。可以使用webpack-bundle-analyzer或rollup-plugin-visualizer进行可视化分析。值得注意的是，bundle 中的 “有效代码” 比例应当高于 60%—— 如果大量体积来自 polyfill 和工具函数，说明存在优化空间。

依赖重复度是容易被忽视的指标。使用npm ls或depcheck工具可以识别同一包的不同版本被同时安装的情况。理想的依赖树中，每个包应当只有一个版本。重复版本不仅增加体积，还会给调试带来额外复杂度。

依赖更新频率也是健康度指标。如果项目中存在超过一年未更新的依赖，需要评估其维护状态和继续使用的必要性。供应链安全事件往往发生在这些 “废弃” 依赖上。

工程优化实践路径

针对依赖膨胀问题，可以从工具层、架构层和流程层三个维度进行优化。

工具层面，推荐使用knip检测未使用的依赖和死代码。这个工具可以扫描项目找出实际未被引用的依赖，帮助识别 “看起来在使用但实际未使用” 的情况。e18e CLI 的analyze模式能够识别哪些依赖可以被原生功能替代 —— 例如chalk可以替换为 Node.js 原生的util.styleText。对于已确定需要替换的依赖，可以使用 e18e 社区维护的module-replacements-codemods进行自动化迁移。npmgraph 是可视化依赖树的好工具，可以直观地看到依赖膨胀的热点区域。

架构层面的优化更加根本。首先应当审查直接依赖的选择标准。对于每新增的一个直接依赖，需要评估其 bundle 贡献、维护活跃度、安全审计记录。对于功能相似的多个依赖，优先选择体积更小、依赖更少的单一库而非多个专用库的组合。对于工具函数类依赖，应当评估内联实现的成本与收益 —— 一个简单的Array.isArray检查并不值得引入外部依赖，其维护成本和潜在安全风险远超几行内联代码的价值。

对于 ponyfill 类依赖，应当建立定期审查机制。每当目标特性的浏览器支持率达到目标阈值（通常是 99% 以上），就应当启动移除 ponyfill 的评估流程。可以使用caniuse数据或node.green来确认特性支持情况。

流程层面建议将依赖审计纳入 CI/CD 流水线。可以配置构建检查，当依赖数量、bundle 体积或依赖重复度超过阈值时发出警告。依赖安全审计如npm audit应当作为构建的必要步骤。对于企业级项目，建议建立内部的可接受依赖白名单，明确允许使用的依赖范围和版本策略。

供应链安全的关联考量

依赖膨胀不仅是性能问题，也是安全风险放大器。2024 年发生的一起事件很好地说明了这一点：某位维护者由于账户被攻破，其名下的数百个微小原子包被植入恶意代码。这些包随后被更高层的库引用，导致大量下游项目受到影响。如果依赖树更精简、如果这些原子代码能够被内联而非通过独立包引用，攻击面将大幅缩小。

供应链安全与依赖优化实际上是同一问题的两个侧面。那些 “仅一行代码” 的包看似无害，但其维护者可能突然变更、账户可能被攻破、域名可能过期。每增加一个依赖，就是为项目的供应链增加一个潜在故障点。将依赖数量控制在合理范围内，本质上也是在控制供应链风险。

JavaScript 依赖图的膨胀是多年积累的生态问题，其解决需要开发者个体和社区的共同努力。当我们在选择依赖时多问一句 “这个包真的必要吗”，当我们在维护仓库时记得移除过时的 polyfill，当我们倾向于内联微小工具函数而非引用独立包，生态就会向更健康的方向演进。e18e 社区正在推动的 “清理行动” 正是这一理念的体现 —— 通过识别和标记可替换的依赖，推动整个生态向更精简的方向演进。每一次依赖选择都是一次投票，我们可以用选择来塑造一个更高效、更安全的 JavaScript 生态。

资料来源：本文主要参考 e18e 社区维护者 James 的《JavaScript 膨胀的三大支柱》一文，文中详细分析了 npm 依赖树的膨胀根源及社区可采取的优化措施。