包管理工具是 JavaScript 生态的标准件。npm 既是 Node.js 默认的包管理器，也是规模靠前的软件注册表，每周下载量以百亿计，承担依赖安装、版本锁定、脚本执行与包发布四件事。理解它的工作机制，是前端与 Node 后端工程化的起点。
一、npm 是什么：双重身份
npm 全称 Node Package Manager，随 Node.js 一起安装，承担两类角色。
| 角色 | 形态 | 核心职责 |
|---|---|---|
| 包管理器 | 命令行工具 npm |
安装、更新、卸载、发布依赖 |
| 软件注册表 | 中心化数据库 registry.npmjs.org | 托管公共包、提供搜索与下载 |
也就是说，本地的 npm 命令行负责”动手”，远端的 registry 负责”存货”。两个角色配合，构成完整的代码共享链路。检查是否就绪，用两个命令：
node -v
npm -v安装 Node.js 时会自带 npm，无需单独下载。
二、为什么需要 npm：依赖地狱的解药
手工管理依赖时常见三种痛：版本混乱、文件复制、协作差异。npm 用三个机制同时解决。
- 声明式依赖：用
package.json列出”项目需要哪些包、各自的版本范围”，避免代码里散落一地require。 - 锁文件：用
package-lock.json记录”实际安装时的精确版本与树结构”，保证团队与 CI 拉到的依赖完全一致。 - 语义化版本（semver）：通过
^、~、=区分兼容性升级与破坏性升级，开发者按规则选号，工具按规则解析。
这三个机制叠加，让”在我电脑上能跑”成为历史。再延伸一层：依赖锁带来的副作用是”升级被显式约束”。这反过来说明，必须有人定期跑 npm outdated 审视依赖，而不是等到生产事故才查。工程化做得好不好，看团队对锁文件的态度就明白一半。
三、核心机制：package.json 与依赖树
package.json 是项目的元数据文件，高频字段包括：
| 字段 | 含义 | 常见写法 |
|---|---|---|
name |
包名 | 短横线分隔，小写 |
version |
版本号 | 遵循 semver（主.次.修） |
dependencies |
生产依赖 | ^4.18.2 兼容小版本 |
devDependencies |
开发依赖 | 测试、构建、格式化工具 |
scripts |
命令别名 | start/test/build |
main |
入口文件 | 默认为 index.js |
执行 npm install 时，npm 会先读 package.json 确定要装的包，再读 package-lock.json 锁定精确版本，然后把依赖树下载到 node_modules。整个下载过程是确定性的，锁文件一旦提交，团队成员和 CI 拉到的内容完全一致。如果遇到”同事能装、我装不上”的玄学，多半就是 lock 文件没同步——删掉重装或 npm ci 走干净安装，往往能解决大半问题。
小贴士：
node_modules体积大且可重生成，应加入.gitignore；只提交package.json与package-lock.json。
四、常用命令清单
下面按使用频次排列，命令与场景一一对应。
| 场景 | 命令 | 备注 |
|---|---|---|
| 初始化项目 | npm init / npm init -y |
-y 跳过问答 |
| 安装所有依赖 | npm install |
按 package.json 安装 |
| 安装生产依赖 | npm i lodash |
写入 dependencies |
| 安装开发依赖 | npm i -D eslint |
写入 devDependencies |
| 安装指定版本 | npm i vue@3.4.0 |
精确锁版本 |
| 全局安装 | npm i -g pnpm |
命令行工具常用 |
| 卸载依赖 | npm un lodash |
同步移除声明 |
| 检查过期 | npm outdated |
列出可升级项 |
| 升级依赖 | npm update |
受 semver 范围限制 |
| 安全审计 | npm audit / npm audit fix |
检测并自动修复漏洞 |
| 运行脚本 | npm run build |
调用 scripts 字段 |
| 登录 | npm login |
发布前必做 |
| 发布 | npm publish |
推送到 registry |
掌握这张表，足以覆盖日常 80% 的操作。
五、发布自己的 npm 包
把内部工具抽成可复用包，是进阶必经之路，流程并不复杂。
- 在项目根目录准备
package.json，重点字段：name（建议带作用域如@your-scope/utils）、version、main/exports、files（白名单，控制上传内容）。 - 写
.npmignore排除测试与构建产物，参考.gitignore写法。 - 本地验证：
npm pack生成压缩包、npm install <tgz>在另一目录试装。 - 登录账号：
npm login（使用作用域包需加--access public）。 - 正式发布：
npm publish；后续迭代用npm version patch|minor|major升号后再 publish。
{
"name": "@your-scope/format-date",
"version": "1.0.0",
"main": "dist/index.js",
"files": ["dist", "README.md"],
"scripts": {
"build": "tsc -p tsconfig.json",
"prepublishOnly": "npm run build"
}
}prepublishOnly 钩子保证每次发布前都跑一次构建，避免把源码而不是产物发出去。版本号按 semver 规则升，breaking change 升 major、新增功能升 minor、修 bug 升 patch。
六、与替代工具的边界
npm 并非唯一选择，pnpm、yarn、bun 都活跃在工程一线。差异集中在三处：
| 维度 | npm | pnpm | yarn (Berry / PnP) |
|---|---|---|---|
| 磁盘占用 | 软链/重复并存 | 硬链接共享 store | 可选 PnP，不写 node_modules |
| 安装速度 | 较慢 | 快 | 快 |
| monorepo 工作区 | 原生支持 | 原生支持 | 原生支持 |
| 兼容性 | 生态默认 | 兼容 npm 生态 | 需调整导入方式（PnP 模式） |
多数团队从 npm 起步，磁盘吃紧或多包仓库时再迁移 pnpm，是稳妥路径。需要补充的是，npm 自身也在持续迭代：从 v7 引入 workspaces、v8 改进安装速度、v9 把 npm audit 的输出与自动修复做得更稳，是工具链里”默认能用、不折腾”那一档。
常见问题（FAQ）
Q1：dependencies 和 devDependencies 到底怎么分？
运行时需要的放 dependencies，只在构建/测试/格式化时用到的放 devDependencies。
Q2：npm i 之后报一堆高危漏洞，多久需要处理一次？
建议每次发版前都跑一遍 npm audit；CI 里加 npm audit --audit-level=high 拦门，发现高危即阻塞流水线。
Q3：哪些情况需要把包发布到内网私有 registry？
公司代码不便公开、SDK 跨团队复用、镜像海外依赖提速这三类场景，建议自建 verdaccio 或使用团队私库，切换源即可发布。
