JavaScript生态之所以繁荣，很大程度上归功于成熟的包管理体系。通过npm或者yarn，开发者可以轻松引入第三方库，把精力集中在业务逻辑上。不过包管理并不只是敲一行install命令那么简单，依赖的分类、版本的锁定、lock文件的提交策略，每一环都直接影响项目的可维护性。这篇文章从实际开发的角度出发，把npm和yarn的使用方法、依赖管理的核心概念讲清楚。
一、先搞懂package.json和依赖的分类
每个Node.js项目的根目录下几乎都有一个package.json文件，它是整个项目的身份证，记录了项目名称、版本、入口文件以及所有依赖信息。理解这个文件是做好包管理的前提。
打开一个典型的package.json，你会看到几个关键字段。dependencies存放的是项目运行时必需的包，比如express、axios、vue这些，打包发布后仍然需要它们才能正常工作。devDependencies存放的则是开发阶段才用到的工具，例如webpack、eslint、各类单元测试框架，这些包不会被打进最终的产物。peerDependencies通常出现在插件类库中，表示当前包需要宿主环境提供某个依赖，比如vue的插件会声明对vue本身的版本要求。
安装时区分这两类依赖非常重要。使用npm install axios默认会装入dependencies，而npm install webpack --save-dev（简写为-D）则会装入devDependencies。如果不小心把构建工具装进了dependencies，会导致生产环境安装一堆无用文件，拖慢部署速度。
{
"name": "my-app",
"version": "1.0.0",
"dependencies": {
"axios": "^1.6.0",
"express": "~4.18.2"
},
"devDependencies": {
"webpack": "^5.89.0",
"eslint": "^8.56.0"
}
}二、语义化版本与版本号规则
细心的话你会发现依赖版本号前面带着^或者~这样的符号，这就是语义化版本（Semantic Versioning）的标记。版本号格式为主版本.次版本.修订号，例如2.3.1。主版本号变化意味着可能存在不兼容的API改动，次版本号代表新增了向下兼容的功能，修订号则只是bug修复。
^1.6.0表示允许安装1.6.0及以上但小于2.0.0的版本，也就是允许次版本和修订号升级。~1.6.0则更保守，只允许修订号升级，即1.6.x范围内。不写任何符号的精确版本如1.6.0会严格安装这个版本。理解这些规则有助于在依赖灵活性和稳定性之间做取舍：库的作者希望用户能自动获得bug修复，但项目维护者往往更倾向锁定版本以保证构建可复现。
正因如此，lock文件出现了。npm生成package-lock.json，yarn生成yarn.lock，它们会记录每个依赖包解析后的确切版本。即使package.json里写的是^1.6.0，lock文件也会固定住实际安装的是1.6.8还是别的版本。团队协作时lock文件必须提交到代码仓库，这样所有成员和CI环境安装出来的依赖树才会完全一致，避免出现"我这台机器上没问题"的经典尴尬。
三、npm的常用命令与使用技巧
npm是Node.js自带的包管理器，无需额外安装。它的核心命令是npm install，可以简写为npm i，不带参数执行时会根据package.json和lock文件安装全部依赖。安装指定包时，npm install lodash会把最新版本写入dependencies，加@版本号可以指定版本，例如npm install lodash@4.17.21。
卸载依赖用npm uninstall lodash，npm会同时从package.json中移除对应条目。查看已安装的依赖列表可以用npm list，加上--depth=0只显示直接依赖。当node_modules出现莫名其妙的问题时，删除整个目录再重新安装往往能解决，npm也提供了清理缓存的命令npm cache clean --force来处理损坏的缓存。
# 安装全部依赖 npm install # 安装生产依赖并指定版本 npm install axios@1.6.0 # 安装开发依赖 npm install -D vite # 卸载依赖 npm uninstall axios # 查看直接依赖列表 npm list --depth=0 # 清理缓存 npm cache clean --force
npm从5.x版本开始引入了lock文件，7.x之后还内置了npx命令用于临时执行包命令，比如npx create-react-app my-app不需要全局安装脚手架就能直接运行。全局安装使用-g参数，适合放置命令行工具类包，但业务依赖千万不要全局安装，否则无法在package.json中追溯。
四、yarn的使用方法与npm的对比
yarn是Facebook团队推出的包管理工具，诞生之初是为了解决npm早期安装速度慢、依赖树不确定的问题。yarn通过并行下载和全局缓存机制大幅提升了安装效率，首次安装后包会被缓存到本地，后续项目再装同一个包几乎是秒级完成。
yarn的命令和npm高度对应，但有几个细节不同：yarn的全局安装不使用-g，而是yarn global add；向脚本传参时yarn不需要额外的双横线；yarn创建项目可以直接用yarn init交互式生成package.json。
# 安装全部依赖 yarn install # 添加生产依赖 yarn add lodash # 添加开发依赖 yarn add -D webpack # 升级依赖到最新版本 yarn upgrade lodash # 删除依赖 yarn remove lodash
对比两者，npm经过多轮迭代后，在速度上已经和yarn相差不大，lock文件机制也早已补齐，二者在功能层面基本拉平。选择哪个更多是团队习惯问题：老项目用npm的继续用npm，用yarn的团队保持yarn即可。需要注意的是，同一个项目里不要混用两个工具，npm和yarn的lock文件格式不同，混用会导致依赖版本再次漂移。现代工程中还可以考虑pnpm，它通过硬链接共享依赖，能显著节省磁盘空间并严格隔离依赖，特别适合monorepo场景。
五、团队协作中的依赖管理最佳实践
多人协作的项目里，依赖管理混乱往往比代码问题更伤人。首先是lock文件必须提交，同时把node_modules加入.gitignore，这是铁律。有些团队为了图省事不提交lock文件，结果每次构建都解析出不同版本的依赖，线上故障排查起来非常痛苦。
其次，升级依赖要有节奏。日常小版本升级可以在分支上跑完测试后合入，而跨主版本的升级建议单独开分支处理，逐个检查Breaking Changes。npm提供了npm outdated命令查看哪些依赖有新版本，yarn对应的也有yarn outdated，定期执行一次能保持依赖的健康度。安全方面，npm audit会扫描依赖树中已知漏洞的包并给出修复建议，把这一步接入CI流水线可以防患于未然。
最后一点建议是克制地引入依赖。每加一个包，项目的构建时间、安装体积和维护成本都会增加，一些只有几行代码的小工具函数，自己实现可能比引入一个几十KB的依赖更划算。依赖清单保持精简，package.json一目了然，才是长期维护下去的好项目该有的样子。
npm依赖管理yarn安装JavaScript包管理修改时间：2026-09-16 04:08:39