逐步淘汰旧的 JavaScript 依赖：CRA、Moment、jQuery 及其他
哪些过时的 JavaScript 库和工具应该逐步淘汰，它们为何会成为负担，有哪些替代品，以及如何防止依赖列表再次出现问题。
来源: **JavaScript Libraries and Tools Heading Toward Deprecation: What to Drop in 2026**
大多数 JavaScript 项目都包含一些在项目创建时看似合理但如今已沦为负担的依赖项：体积庞大的代码包、未修复的安全漏洞、与现代运行时不兼容的问题，或是平台现已免费提供的功能。这些问题不会一夜之间导致系统崩溃，也正是它们能长期存在的原因。本指南将介绍那些已过时、处于维护模式或逐渐被淘汰的库和工具，解释每一种为何落后于时代，并推荐相应的替代方案，帮助你有条不紊地规划迁移，而非在压力之下仓促行事。
构建与脚手架工具
Create React App
多年来，Create React App（CRA）一直是创建React项目的标准工具。2025年初，React团队正式宣布不再将其作为新应用的启动方式，且该工具也不再获得实质性更新，因此其技术栈中的安全问题始终得不到解决。随着越来越多的团队转向其他工具，它的下载量也在迅速下降。
其背后的原因在于结构性问题：没有人主动维护它，其对代码打包和开发服务器的假设已经过时，而替代方案则能满足现代需求，如服务端渲染、更快的构建速度以及无需额外配置即可提升的开发体验。优秀的替代工具包括：
- 对于典型的单页应用，可使用Vite搭配
@vitejs/plugin-react - 如果应用需要路由、数据获取机制或服务端代码，则可选择Next.js、Remix/React Router或其他完整框架
由于 CRA 应用主要由标准 React 代码加上隐藏的构建配置构成，因此迁移工作量通常远低于团队预期：只需更换构建工具、调整 HTML 入口点及环境变量规范，组件本身无需改动。如果是从零开始，我们的 React 和 Vite 设置指南中的步骤可帮助你掌握新的基础配置。
新项目推荐使用 Webpack
Webpack 远未走向衰落。仍有大量生产级应用使用它进行构建，而且这一状况短期内不会改变。有所下降的是它在新项目中的占比，主要原因在于其配置较为复杂，冷启动速度也慢于 newer 工具。对于全新的前端项目，Vite 是目前的默认选择，Rspack 和基于 esbuild 的方案也是不错的选择。对于那些配置极为复杂的项目，Webpack 依然适用，但新项目很少会从它开始。如需更深入地比较这些选项，请参阅 选择打包工具。
该平台已整合的库
Moment.js
几乎每位 JavaScript 开发者都曾使用过 Moment.js。其维护团队早已将其定义为处于维护模式的遗留项目。该库体积庞大，其对象默认是可变的（当某个地方的日期被修改而其他地方却仍显示旧值时，这往往是错误的根源），而且难以进行代码压缩优化。
原生的日期处理功能已得到改进，现在有一些小巧且不可变的库能够以更好的性能完成相同任务。按推荐程度大致排序，您的选择如下：
Intl.DateTimeFormat，用于实现符合本地习惯的日期格式化- Temporal，这是开发者们期待已久的新型内置日期和时间 API，正在逐步被各种运行时环境和浏览器支持；在依赖它之前，请先确认目标环境是否已具备相应支持
- 如果仍需要外部库，可选择 date-fns、Luxon 或 Day.js
如果您的依赖树中仍包含 Moment，那就安排进行迁移吧。仅通过减少包的大小往往就能带来显著效果。
jQuery
在2010年代，jQuery解决了真正的跨浏览器兼容问题。但对于如今的新增代码而言，几乎再也没有使用它的必要了，因为标准化的DOM API、fetch以及各种组件框架已经能够处理它曾经需要解决的各类问题。使用纯JavaScript配合querySelector、classList、addEventListener以及原生的fetch功能即可完成大多数直接的DOM操作，而当需要基于组件的界面时，则可以使用React、Vue、Svelte或Solid等框架。现有的旧代码库可能会在多年内继续使用jQuery，这并无不妥，但在全新的项目中还使用它则是一个警示信号。
Lodash和Underscore
在 ES2015 出现之前，Lodash 几乎是不可或缺的。如今，它的大部分辅助函数都有原生替代方案：诸如 map、filter 和 reduce 这样的数组方法，Object.entries，可选链操作符、空值合并运算符等等。为了使用少数几个函数而引入整个库甚至其中的大部分内容，实在难以找到合理的理由。应当从语言本身出发，仅在原生 API 真正存在不足的情况下再添加针对性的工具函数，比如深度相等性比较或防抖功能。我们在 关于可替代工具函数依赖的原生特性的文章 中列举了具体的替换案例。
测试与网络功能
Enzyme
很长一段时间里，Enzyme都是测试React组件的主要工具，但它始终无法很好地适配React 18及其并发特性，因此使用率急剧下降。由于Enzyme侧重于测试组件的内部结构（状态、实例方法、浅层渲染树），进行迁移在某种程度上意味着需要改变思维方式。而社区和React团队共同推荐的React Testing Library则侧重于测试用户所看到的界面及操作行为，可搭配Vitest或Jest作为执行工具使用。
request与node-fetch v2
request早已被正式废弃，不再获得安全补丁，因此任何仍在使用它的做法都存在明显风险。node-fetch v2的下载量也大幅下降，因为Node.js 18及更高版本已内置全局fetch函数（早期版本中该功能被标记为实验性，需在您的Node版本上确认其实际行为）。请使用原生的fetch函数，它现已在现代Node环境及所有当前浏览器中正常工作。如果需要重试、拦截器或更强大的流处理功能，可以考虑使用undici、ky或got。
其他值得关注的内容
还有几项变更也应在您的升级清单上：
- 根据发布计划，ESLint 9.x将于2026年8月达到生命周期终点；建议规划升级到v10系列，并在ESLint官网确认具体日期。
@aws-sdk/* 下的模块化 v3 客户端，这样只需导入实际使用的客户端即可。保持依赖项最新的常规做法
仅仅更换一次这些库是不够的，关键是要养成习惯，防止新的过时依赖项不断积累。
- 定期检查
package.json，并运行npm outdated和npm audit，以便及时发现依赖项的变动情况。
fetch 函数、在支持的情况下使用 Temporal，以及当前主流版本的框架。一个值得牢记的权衡点：并非所有的旧版依赖都亟需立即重写。那些使用 jQuery 或 Webpack 的稳定内部工具，其迁移成本可能远高于能带来的收益。应根据依赖的暴露程度来确定优先级：任何未维护且涉及网络、用户输入或构建流程的依赖（如 request、CRA、AWS SDK v2）都应优先处理；像 Moment 和 Lodash 这类会增大包大小的依赖次之；纯粹出于风格上的现代化改造则可以延后。
关键要点
- 已废弃且未维护的包首先构成安全风险，其次才是性能问题，因此应按风险程度来安排迁移顺序。
- 许多曾经的常用库（如 Moment、Lodash、jQuery、
request）已被编程语言、DOM 或运行时所整合，因此替换后的代码体积会比原有依赖更小。