告别冗余依赖：用Baseline策略精简JavaScript打包

在前端开发中，我们常常陷入一种惯性思维：“我需要一个库来实现这个功能”。然而，现实是，浏览器原生支持的能力正在快速追赶甚至超越许多流行工具的功能。这种“你需要一个库”与“浏览器直接支持”之间的鸿沟，正在以前所未有的速度弥合。

这篇文章并非倡导完全摒弃所有第三方库，而是提供一个清晰的路线图，帮助你审计项目依赖，找出那些可以被现代浏览器原生能力安全替代的部分，从而交付更精简、更高效的JavaScript。

认识“Baseline”：你的浏览器能力指南针

我们所说的“Baseline”，并非某个具体工具，而是一种策略和思维框架。它指的是基于浏览器原生API的稳定可用性（通常指在所有主流浏览器中支持已达到一定时间或覆盖绝大多数用户），来决定是否需要引入一个外部依赖。

简单来说，在决定添加一个新库之前，先问自己：

对现有项目进行依赖“瘦身”，可以遵循以下步骤：

使用 npm ls --prod 或查看 package.json，清晰地列出所有生产环境依赖。像 bundlephobia.com 这样的工具可以帮助你直观了解每个依赖包的体积及其子依赖树。

将依赖按功能分类（如：HTTP请求、日期处理、CSS布局、动画、本地存储等），然后尝试将其与Web平台能力进行映射。例如：

库功能	浏览器原生替代方案
`axios` / `got`（请求）	`fetch` API（已非常成熟）
`moment.js` / `dayjs`（日期）	`Temporal` API（逐步可用中）、原生 `Date` 对象 + `Intl`
`lodash` 中的部分工具函数	例如 `_.debounce` 可用原生实现，`Array.prototype.includes` 替代 `_.contains`
`styled-components` (CSS-in-JS)	CSS 原生嵌套、`:has()` 选择器、CSS 变量等新特性
`framer-motion` (动画)	Web Animations API 和 CSS 动画/过渡

对于每个映射成功的库，进行三重评估：

功能覆盖度：浏览器API是否覆盖了我实际用到的90%以上功能？
兼容性：通过 Can I Use 等工具，确认API在目标浏览器环境中的支持率。可以使用 Baseline 作为参考——查看MDN或Chrome团队发布的Baseline特性列表。
切换成本：重写为原生API所需的工作量、测试成本以及维护成本如何？

完全替换往往不现实。一个更稳妥的策略是：

封装底层API：如果决定使用原生 fetch，可以在项目内部创建一个轻量的封装层（wrapper），统一错误处理、拦截器等功能。这样既能减少对大型HTTP客户端的依赖，又保持了代码的整洁和可维护性。

逐步替换：在新功能开发中强制使用原生方案，同时在旧模块的维护中，寻找机会逐步替换。这有助于分散风险。

moment.js 是一个经典但臃肿的库。通过Baseline审计，我们可以看到：

虽然Temporal完全稳定尚需时间，但对于很多项目来说，一个结合了 Date、Intl 以及少量自定义工具函数的方案，其体积可能只有 moment.js 的百分之一，且无需额外下载。这种深度的依赖分析，正是Baseline策略的核心价值。

前端生态的繁荣带来了选择，也带来了负担。Baseline策略鼓励我们重新审视与浏览器的关系——它不再是一个功能贫乏的运行环境，而是一个不断进化的强大平台。

通过定期审计依赖，勇敢地拥抱原生API，我们不仅能为用户带来更快的加载速度和更流畅的体验，也能让自己的技术栈更加健壮和面向未来。下一次，当你准备安装一个新库时，不妨先停一下，看看浏览器本身能为你做些什么。

进一步阅读：