嘿，这在使用旧项目或学习老教程时太常见了！先给你吃颗定心丸：你看到的这些npm WARN deprecated警告只是包作者标记了对应版本不再维护，但npm仍然会按照package.json里指定的版本安装依赖，你的项目大概率还是能正常运行的，这些警告更多是提醒你潜在的安全或维护风险。

接下来逐个解答你的疑问：

1. 为何无法直接使用package.json中指定的版本？ #

其实你完全可以使用！npm并没有阻止安装这些版本，那些警告只是因为这些包的版本被作者标记为「废弃（deprecated）」了——可能是包改名了（比如angular-ui-router改成了@uirouter/angularjs）、存在安全漏洞、不再适配新的Node.js/浏览器版本，或者有更成熟的替代方案。

package.json里的版本通常带有范围符号（比如^或~），npm会安装符合这个范围的最新版本，但如果这个范围内的所有版本都被废弃了，就会弹出这些警告。本质上你安装的还是package.json指定范围内的版本，只是官方不再推荐使用它们了。

2. 让项目正常运行的通用流程 #

给你一套稳妥的操作步骤：

• 第一步：先尝试直接运行项目
  先执行教程里的启动命令（比如npm start或对应的gulp/webpack命令），很多时候虽然警告一堆，但旧版本依赖仍然能正常工作——毕竟教程当时是能跑通的。如果运行正常，完全可以先跟着教程学习，之后再考虑升级的事。
• 第二步：如果项目无法运行，再逐步处理依赖
  要是启动报错，千万别直接把所有依赖更到最新版本！像AngularJS这类老框架的项目，依赖之间有严格的版本兼容性，盲目升级最新版大概率会出现API不兼容的问题。正确做法是：
  • 逐个处理废弃警告：比如angular-ui-router@0.2.18需要替换成@uirouter/angularjs，先确认新包和你项目里AngularJS的版本是否匹配；
  • 优先替换有安全风险的依赖：比如那些提到RegExp DoS问题的minimatch、debug，先升级到警告里推荐的安全版本；
  • 每次修改package.json后执行npm install，然后测试项目是否能正常运行，避免一次性改太多导致排查困难；
  • 保留package-lock.json：这个文件会锁定你实际安装的依赖版本，确保之后再安装或其他人下载项目时，能得到完全相同的依赖环境。

3. 旧GitHub项目出现这类问题是普遍现象吗？ #

绝对是！npm生态更新速度非常快，几个月前的项目可能就有依赖被废弃，更别说几年前的教程项目了。处理这类「依赖腐烂（dependency rot）」是开发者日常工作中很常见的场景——不管是维护公司的旧项目，还是学习网上的老教程，几乎都会遇到。这也是开发者需要掌握的基础技能之一：理解依赖版本规则、排查兼容性问题、替换废弃依赖。

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