前端工程化（5）：你所须要的npm知识储备都在这了

npm在前端开发流程中提供了很是完善的自动化工具链，已成为每一个前端开发者必备的工具，可是一样因为其强大性致使不少前端开发者只会简单的使用它。本文将总结在平常开发中所须要的npm知识点，以便开发者们更好的将npm运用在实际开发中。

1. npm install 机制

咱们都知道，npm install用来给项目中安装依赖包，对于其是如何安装的却每每被人忽略。由于不少同窗在实际开发中只关注依赖包提供的功能，而不关注依赖包所处的层级关系。依赖包安装错综复杂，这也致使不少同窗在安装包出现问题的时候不知所措。因此，咱们仍是有必要去了解npm install的机制，以至于咱们可以更从容的面对安装问题。

假设项目App中有以下三个依赖：

"dependencies": {
    A: "1.0.0",
    B: "1.0.0",
    C: "1.0.0"
}
复制代码

A、B、C三个模块又有以下依赖：

A@1.0.0 -> D@1.0.0

B@1.0.0 -> D@2.0.0

C@1.0.0 -> D@2.0.0
复制代码

嵌套安装

在npm 2.x时代，安装依赖方式比较简单直接，以递归的方式，按照包依赖的树形结构下载填充本地目录结构，也就是说每一个包都会将该包的依赖安装到当前包所在的node_modules目录中。

执行npm install后，项目App的node_modules会变成以下目录结构：

├── node_modules
│   ├── A@1.0.0
│   │   └── node_modules
│   │   │   └── D@1.0.0
│   ├── B@1.0.0
│   │   └── node_modules
│   │   │   └── D@2.0.0
│   └── C@1.0.0
│   │   └── node_modules
│   │   │   └── D@2.0.0
复制代码

很显然这样的依赖组织结构，有以下优势：

• 层级结构明显
• 简单的实现了多版本兼容
• 保证了对依赖包不管是安装仍是删除都会有统一的行为和结构

可是缺点也同样很明显：

• 可能形成相同模块大量冗余问题
• 可能形成目录结构嵌套比较深的问题

扁平安装

从npm 3.x开始就采用了扁平化的结构来安装模块（因为笔者都是在npm 6.14.5的版本下进行验证，因此这一小结包括后面的论述都是基于该版本进行阐述），它会遍历全部依赖树节点，逐个将模块放在一级node_modules中，当发现有重复模块时，则将其丢弃。

还以项目App为例，执行npm install后，node_modules会变成以下目录结构：

├── node_modules
│   ├── A@1.0.0
│   │   └── node_modules
│   │   │   └── D@1.0.0
│   ├── B@1.0.0
│   ├── C@1.0.0
│   └── D@2.0.0
复制代码

能够看到，D@2.0.0模块被安装在一级node_modules中，而D@1.0.0仍被安装在A@1.0.0中。因此能够得出结论，在执行npm install安装时，若是遇到相同依赖的包，会优先将高版本（大版本）的包放在一级node_modules中，低版本的包则会按照npm 2.x的方式依次挂在依赖包的node_modules中。

再在项目中安装模块E@1.0.0（依赖于模块D@1.0.0），目录结构变为：

├── node_modules
│   ├── A@1.0.0
│   │   └── node_modules
│   │   │   └── D@1.0.0
│   ├── B@1.0.0
│   ├── C@1.0.0
│   ├── D@2.0.0
│   ├── E@1.0.0
│   │   └── node_modules
│   │   │   └── D@1.0.0
复制代码

能够看到，E模块下仍会安装模块D@1.0.0。因此能够得出结论，在一级node_moudles中已经存在依赖包的状况下，新安装的依赖包若是存在版本冲突，则仍会安装到新依赖包的node_modules中。

再在项目中安装模块F@1.0.0（依赖于模块D@2.0.0），目录结构变为：

├── node_modules
│   ├── A@1.0.0
│   │   └── node_modules
│   │   │   └── D@1.0.0
│   ├── B@1.0.0
│   ├── C@1.0.0
│   ├── D@2.0.0
│   ├── E@1.0.0
│   │   └── node_modules
│   │   │   └── D@1.0.0
│   └── F@1.0.0
复制代码

能够看到，只会安装F模块。因此能够得出结论，在一级node_moudles中已经存在依赖包的状况下，新安装的依赖包若是不存在版本冲突，则会忽略安装。

从以上示例能够看出，npm 6.x并无完美的解决npm 2.x中的问题，甚至还会退化到npm 2.x的行为。

为了解决目录中存在不少副本的状况，能够经过npm dedupe指令把全部二级的依赖模块D@1.0.0重定向到一级目录下（前提是所依赖的D@1.0.0模块升级到了D@2.0.0）：

├── node_modules
│   ├── A@1.0.0
│   ├── D@2.0.0
│   ├── B@1.0.0
│   ├── C@1.0.0
│   ├── E@1.0.0
│   └── F@1.0.0
复制代码

node_modules路径查找机制：模块在找对应的依赖包时，nodejs会尝试从当前模块所在目录开始，尝试在它的node_modules 文件夹里加载相应模块，若是没有找到，那么就再向上一级目录移动，直到全局安装路径中的node_modules为止。

package-lock.json

从npm 5.x开始，执行npm install时会自动生成一个package-lock.json 文件。

npm为了让开发者在安全的前提下使用最新的依赖包，在package.json中一般作了锁定大版本的操做，这样在每次npm install的时候都会拉取依赖包大版本下的最新的版本。这种机制最大的一个缺点就是当有依赖包有小版本更新时，可能会出现协同开发者的依赖包不一致的问题。

package-lock.json文件精确描述了node_modules 目录下全部的包的树状依赖结构，每一个包的版本号都是彻底精确的。以sass-loader在package-lock.json中为例：

"dependencies": {
  "sass-loader": {
    "version": "7.1.0",
    "resolved": "http://registry.npm.taobao.org/sass-loader/download/sass-loader-7.1.0.tgz",
    "integrity": "sha1-Fv1ROMuLQkv4p1lSihly1yqtBp0=",
    "dev": true,
    "requires": {
      "clone-deep": "^2.0.1",
      "loader-utils": "^1.0.1",
      "lodash.tail": "^4.1.1",
      "neo-async": "^2.5.0",
      "pify": "^3.0.0",
      "semver": "^5.5.0"
    },
    "dependencies": {
      "pify": {
        "version": "3.0.0",
        "resolved": "http://registry.npm.taobao.org/pify/download/pify-3.0.0.tgz",
        "integrity": "sha1-5aSs0sEB/fPZpNB/DbxNtJ3SgXY=",
        "dev": true
      }
    }
  }
}

复制代码

package-lock.json的详细描述主要由version、resolved、integrity、dev、requires、dependencies这几个字段构成：

• version：包惟一的版本号
• resolved：安装源
• integrity：代表包完整性的hash值（验证包是否已失效）
• dev：若是为true，则此依赖关系仅是顶级模块的开发依赖关系或者是一个的传递依赖关系
• requires：依赖包所须要的全部依赖项，对应依赖包package.json里dependencies中的依赖项
• dependencies：依赖包node_modules中依赖的包，与顶层的dependencies同样的结构

在上面的package-lock.json文件中能够发现，在requires和dependencies中都存在pify依赖项。那咱们顺便去node_modules里面探下究竟：

1. 打开根目录的node_modules会发现安装了sass-loader所须要的全部依赖包，这些依赖包中除了pify之外，全部依赖包的大版本号都与sass-loader所须要的一致。
2. 到根目录的node_modules找到pify依赖包，发现版本为4.0.1。
3. 找到sass-loader项目依赖包，打开其node_modules发现其中也存在个pify依赖包，但版本为3.0.0。这个版本的sass-loader真正依赖的是这个版本的pify。

经过以上几个步骤，说明package-lock.json文件和node_modules目录结构是一一对应的，即项目目录下存在package-lock.json可让每次安装生成的依赖目录结构保持相同。

在开发一个应用时，建议把package-lock.json文件提交到代码版本仓库，从而让你的团队成员、运维部署人员或CI系统能够在执行npm install时安装的依赖版本都是一致的。

可是在开发一个库时，则不该把package-lock.json文件发布到仓库中。实际上，npm也默认不会把package-lock.json文件发布出去。之因此这么作，是由于库项目通常是被其余项目依赖的，在不写死的状况下，就能够复用主项目已经加载过的包，而一旦库依赖的是精确的版本号那么可能会形成包的冗余。

2. npm 中的依赖包

依赖包分类

在 node 中其实总共有5种依赖：

• dependencies - 业务依赖

• devDependencies - 开发依赖

• peerDependencies - 同伴依赖

• bundledDependencies / bundleDependencies - 打包依赖

• optionalDependencies - 可选依赖

做为npm的使用者，咱们经常使用的依赖是dependencies和devDependencies，剩下三种依赖则是做为包的发布者才会使用到的字段。

dependencies

这种依赖在项目最终上线或者发布npm包时所须要，即其中的依赖项应该属于线上代码的一部分。好比框架vue，第三方的组件库element-ui等，这些依赖包都是必须装在这个选项里供生产环境使用。

经过命令npm install/i packageName -S/--save把包装在此依赖项里。若是没有指定版本，直接写一个包的名字，则安装当前npm仓库中这个包的最新版本。若是要指定版本的，能够把版本号写在包名后面，好比npm i vue@3.0.1 -S。

从npm 5.x开始，能够不用手动添加-S/--save指令，直接执行npm i packageName把依赖包添加到dependencies中去。

devDependencies

这种依赖只在项目开发时所须要，即其中的依赖项不该该属于线上代码的一部分。好比构建工具webpack、gulp，预处理器babel-loader、scss-loader，测试工具e2e、chai等，这些都是辅助开发的工具包，无须在生产环境使用。

经过命令npm install/i -D/--save-dev把包安装成开发依赖。若是想缩减安装包，可使用命令npm i --production忽略开发依赖，只安装基本依赖，这一般在线上机器（或者QA环境）上使用。

千万别觉得只有在dependencies中的模块才会被一块儿打包，而在devDependencies中的不会！模块可否被打包，取决于项目里是否被引入了该模块！

在业务项目中dependencies和devDependencies没有什么本质区别，只是单纯的一个规范做用，在执行npm i时两个依赖下的模块都会被下载；而在发布npm包的时候，包中的dependencies依赖项在安装该包的时候会被一块儿下载，devDependencies依赖项则不会。

peerDependencies

这种依赖的做用是提示宿主环境去安装插件在peerDependencies中所指定依赖的包，而后插件所依赖的包永远都是宿主环境统一安装的npm包，最终解决插件与所依赖包不一致的问题。

这句话听起来可能有点拗口，举个例子来给你们说明下。element-ui@2.6.3只是提供一套基于vue的ui组件库，但它要求宿主环境须要安装指定的vue版本，因此你能够看到element项目中的package.json中具备一项配置：

"peerDependencies": {
    "vue": "^2.5.16"
}
复制代码

它要求宿主环境安装3.0.0 > vue@ >= 2.5.16的版本，也就是element-ui的运行依赖宿主环境提供的该版本范围的vue依赖包。

在安装插件的时候，peerDependencies在npm 2.x和npm 3.x中表现不同：

在npm 2.x中，安装包中peerDependencies所指定的依赖会随着npm install packageName一块儿被强制安装，而且peerDependencies中指定的依赖会安装在宿主环境中，因此不须要在宿主环境的package.json文件中指定对所安装包中peerDependencies内容的依赖。

在npm 3.x中，不会再要求peerDependencies所指定的依赖包被强制安装，npm 3.x只会在安装结束后检查本次安装是否正确，若是不正确会给用户打印警告提示，好比提示用户有的包必须安装或者有的包版本不对等。

大白话：若是你安装我，那么你最好也要按照个人要求安装A、B和C。

bundledDependencies / bundleDependencies

这种依赖跟npm pack打包命令有关。假设package.json中有以下配置：

{
  "name": "font-end",
  "version": "1.0.0",
  "dependencies": {
    "fe1": "^0.3.2",
    ...
  },
  "devDependencies": {
    ...
    "fe2": "^1.0.0"
  },
  "bundledDependencies": [
    "fe1",
    "fe2"
  ]
}
复制代码

执行打包命令npm pack，会生成front-end-1.0.0.tgz压缩包，而且该压缩包中包含fe1和fe2两个安装包，这样使用者执行npm install front-end-1.0.0.tgz也会安装这两个依赖。

在bundledDependencies中指定的依赖包，必须先在dependencies和devDependencies声明过，不然打包会报错。

optionalDependencies

这种依赖中的依赖项即便安装失败了，也不影响整个安装的过程。须要注意的是，若是一个依赖同时出如今dependencies和optionalDependencies中，那么optionalDependencies会得到更高的优先级，可能形成一些预期以外的效果，因此尽可能要避免这种状况发生。

在实际项目中，若是某个包已经失效，咱们一般会寻找它的替代者，或者换一个实现方案。不肯定的依赖会增长代码判断和测试难度，因此这个依赖项仍是尽可能不要使用。

依赖包版本号

npm采用了semver规范做为依赖版本管理方案。

按照semver的约定，一个npm依赖包的版本格式通常为：主版本号.次版本号.修订号（x.y.z），每一个号的含义是：

• 主版本号（也叫大版本，major version）

  大版本的改动极可能是一次颠覆性的改动，也就意味着可能存在与低版本不兼容的API或者用法，（好比 vue 2 -> 3)。

• 次版本号（也叫小版本，minor version）

  小版本的改动应当兼容同一个大版本内的API和用法，所以应该让开发者无感。因此咱们一般只说大版本号，不多会精确到小版本号。

  若是大版本号是 0 的话，表示软件处于开发初始阶段，一切均可能随时被改变，可能每一个小版本之间也会存在不兼容性。因此在选择依赖时，尽可能避开大版本号是 0 的包。

• 修订号（也叫补丁，patch）

  通常用于修复bug或者很细微的变动，也须要保持向前兼容。

常见的几个版本格式以下：

• "1.2.3"

  表示精确版本号。任何其余版本号都不匹配。在一些比较重要的线上项目中，建议使用这种方式锁定版本。

• "^1.2.3"

  表示兼容补丁和小版本更新的版本号。官方的定义是“可以兼容除了最左侧的非 0 版本号以外的其余变化”(Allows changes that do not modify the left-most non-zero digit in the [major, minor, patch] tuple)。这句话很拗口，举几个例子你们就明白了：

  "^1.2.3" 等价于 ">= 1.2.3 < 2.0.0"。即只要最左侧的 "1" 不变，其余均可以改变。因此 "1.2.4", "1.3.0" 均可以兼容。
  
  "^0.2.3" 等价于 ">= 0.2.3 < 0.3.0"。由于最左侧的是 "0"，那么只要第二位 "2" 不变，其余的都兼容，好比 "0.2.4" 和 "0.2.99"。
  
  "^0.0.3" 等价于 ">= 0.0.3 < 0.0.4"。大版本号和小版本号都为 "0" ，因此也就等价于精确的 "0.0.3"。
  复制代码

  从这几个例子能够看出，^ 是一个兼具更新和安全的写法，可是对于大版本号为 1 和 0 的版本仍是会有不一样的处理机制的。

• "~1.2.3"

  表示只兼容补丁更新的版本号。关于 ~ 的定义分为两部分：若是列出了小版本号（第二位），则只兼容补丁（第三位）的修改；若是没有列出小版本号，则兼容第二和第三位的修改。咱们分两种状况理解一下这个定义：

  "~1.2.3" 列出了小版本号 "2"，所以只兼容第三位的修改，等价于 ">= 1.2.3 < 1.3.0"。
  
  "~1.2" 也列出了小版本号 "2"，所以和上面同样兼容第三位的修改，等价于 ">= 1.2.0 < 1.3.0"。
  
  "~1" 没有列出小版本号，能够兼容第二第三位的修改，所以等价于 ">= 1.0.0 < 2.0.0"
  复制代码

  从这几个例子能够看出，~ 是一个比^更加谨慎安全的写法，并且~并不对大版本号 0 或者 1 区别对待，因此 "~0.2.3" 与 "~1.2.3" 是相同的算法。当首位是 0 而且列出了第二位的时候，二者是等价的，例如 "~0.2.3" 和 "^0.2.3"。

• "1.x" 、"1.X"、1.*"、"1"、"*"

  表示使用通配符的版本号。x、X、* 和 （空） 的含义相同，都表示能够匹配任何内容。具体来讲：

  "*" 、"x" 或者 （空） 表示能够匹配任何版本。
  
  "1.x", "1.*" 和 "1" 表示匹配主版本号为 "1" 的全部版本，所以等价于 ">= 1.0.0 < 2.0.0"。
  
  "1.2.x", "1.2.*" 和 "1.2" 表示匹配版本号以 "1.2" 开头的全部版本，所以等价于 ">= 1.2.0 < 1.3.0"。
  复制代码

• "1.2.3-alpha.1"、"1.2.3-beta.1"、"1.2.3-rc.1"

  带预发布关键词的版本号。先说说几个预发布关键词的定义：

  alpha(α)：预览版，或者叫内部测试版；通常不向外部发布，会有不少bug；通常只有测试人员使用。
  
  beta(β)：测试版，或者叫公开测试版；这个阶段的版本会一直加入新的功能；在alpha版以后推出。
  
  rc(release candidate)：最终测试版本；可能成为最终产品的候选版本，若是未出现问题则可发布成为正式版本。
  复制代码

  以包开发者的角度来考虑这个问题：假设当前线上版本是 "1.2.3"，若是我做了一些改动须要发布版本 "1.2.4"，但我不想直接上线（由于使用 "~1.2.3" 或者 "^1.2.3" 的用户都会直接静默更新），这就须要使用预发布功能。所以我可能会发布 "1.2.4-alpha.1" 或者 "1.2.4-beta.1" 等等。

  ">1.2.4-alpha.1"表示接受 "1.2.4-alpha" 版本下全部大于 1 的预发布版本。所以 "1.2.4-alpha.7" 是符合要求的，但 "1.2.4-beta.1" 和 "1.2.5-alpha.2" 都不符合。此外若是是正式版本（不带预发布关键词），只要版本号符合要求便可，不检查预发布版本号，例如 "1.2.5", "1.3.0" 都是承认的。
  
  "~1.2.4-alpha.1" 表示 ">=1.2.4-alpha.1 < 1.3.0"。这样 "1.2.5", "1.2.4-alpha.2" 都符合条件，而 "1.2.5-alpha.1", "1.3.0" 不符合。
  
  "^1.2.4-alpha.1" 表示 ">=1.2.4-alpha.1 < 2.0.0"。这样 "1.2.5", "1.2.4-alpha.2", "1.3.0" 都符合条件，而 "1.2.5-alpha.1", "2.0.0" 不符合。
  复制代码

版本号还有更多的写法，例如范围（a - b），大于等于号（>=），小于等于号（<=），或（||）等等，由于用的很少，这里再也不展开。详细的文档能够参见语义化版本(semver)。它同时也是一个 npm 包，能够用来比较两个版本号的大小，以及是否符合要求等。

依赖包版本管理

npm 2.x/3.x已成为过去式，在npm 5.x以上环境下（版本最好在5.6以上，由于在5.0 ~ 5.6中间对package-lock.json的处理逻辑更新过几个版本，5.6以上才开始稳定），管理项目中的依赖包版本你应该知道（以^版本为例，其余类型版本参照便可）：

1. 在大版本相同的前提下，若是一个模块在package.json中的小版本要大于package-lock.json中的小版本，则在执行npm install时，会将该模块更新到大版本下的最新的版本，并将版本号更新至package-lock.json。若是小于，则被package-lock.json中的版本锁定。

// package-lock.json 中原版本
"clipboard": {
  "version": "1.5.10", 
},
"vue": {
  "version": "2.6.10",
}
// package.json 中修改版本
"dependencies": {
  "clipboard": "^1.5.12",
  "vue": "^2.5.6"
  ...
}

// 执行完 npm install 后，package-lock.json 中
"clipboard": {
  "version": "1.7.1", // 更新到大版本下的最新版本
},
"vue": {
  "version": "2.6.10", // 版本没发生改变
}
复制代码

2. 若是一个模块在package.json和package-lock.json中的大版本不相同，则在执行npm install时，都将根据package.json中大版本下的最新版本进行更新，并将版本号更新至package-lock.json。

// package-lock.json 中原版本
"clipboard": {
  "version": "2.0.4",
}
// package.json 中修改版本
"dependencies": {
  "clipboard": "^1.6.1",
}

// 执行完npm install后，package-lock.json 中
// 
"clipboard": {
  "version": "1.7.1", // 更新到大版本下的最新版本
}
复制代码

3. 若是一个模块在package.json中有记录，而在package-lock.json中无记录，执行npm install后，则会在package-lock.json生成该模块的详细记录。同理，一个模块在package.json中无记录，而在package-lock.json中有记录，执行npm install后，则会在package-lock.json删除该模块的详细记录。

4. 若是要更新某个模块大版本下的最新版本（升级小版本号），请执行以下命令：

npm update packageName # npm updata 只更新顶层模块，而不更新依赖的依赖
复制代码

5. 若是要更新到指定版本号（升级大版本号），请执行以下命令：

npm install packageName@x.x.x
复制代码

6. 卸载某个模块，请执行以下命令：

npm uninstall packageName
复制代码

7. 安装模块的确切版本：

npm install packageName -D/S --save-exact  # 安装的版本号将会是精准的，版本号前面不会出现^~字符
复制代码

经过上述的命令来管理依赖包，package.json和package-lock.json中的版本号都将会随之更新。

咱们在升级/卸载依赖包的时候，尽可能经过命令来实现，避免手动修改package.json中的版本号，尤为不要手动修改package-lock.json。

3. npm scripts 脚本

package.json中的 scripts 字段能够用来自定义脚本命令，它的每个属性，对应一段脚本。以vue-cli3为例：

"scripts": {
  "serve": "vue-cli-service serve",
  ...
}
复制代码

这样就能够经过npm run serve脚本代替vue-cli-service serve脚原本启动项目，而无需每次敲一遍这么冗长的脚本。

npm run是npm run-script的缩写，通常都使用前者，可是后者能够更好地反应这个命令的本质。

工做原理

package.json 中的 bin 字段

package.json中的字段 bin 表示的是一个可执行文件到指定文件源的映射。经过npm bin指令显示当前项目的bin目录的路径。例如在@vue/cli的package.json中：

"bin": {
  "vue": "bin/vue.js"
}
复制代码

若是全局安装@vue/cli的话，@vue/cli源文件会被安装在全局源文件安装目录（/user/local/lib/node_modules）下，而npm会在全局可执行bin文件安装目录（/usr/local/bin）下建立一个指向/usr/local/lib/node_modules/@vue/cli/bin/vue.js文件的名为vue的软连接，这样就能够直接在终端输入vue来执行相关命令。以下图所示：

若是局部安装@vue/cli的话，npm则会在本地项目./node_modules/.bin目录下建立一个指向./node_moudles/@vue/cli/bin/vue.js名为vue的软连接，这个时候须要在终端中输入./node_modules/.bin/vue来执行（也可使用npx vue命令来执行，npx 的做用就是为了方便调用项目内部安装的模块）。

软连接（符号连接）是一类特殊的可执行文件， 其包含有一条以绝对路径或者相对路径的形式指向其它文件或者目录的引用。在bin目录下执行ll指令能够查看具体的软连接指向。在对连接文件进行读或写操做的时候，系统会自动把该操做转换为对源文件的操做，但删除连接文件时，系统仅仅删除连接文件，而不删除源文件自己。

PATH 环境变量

在terminal中执行命令时，命令会在PATH环境变量里包含的路径中去寻找相同名字的可执行文件。局部安装的包只在./node_modules/.bin中注册了它们的可执行文件，不会被包含在PATH环境变量中，这个时候在terminal中输入命令将会报没法找到的错误。

那为何经过npm run能够执行局部安装的命令行包呢？

是由于每当执行npm run时，会自动新建一个Shell，这个 Shell会将当前项目的node_modules/.bin的绝对路径加入到环境变量PATH中，执行结束后，再将环境变量PATH恢复原样。

咱们来验证下这个说法。首先执行 env 查看当前全部的环境变量，能够看到PATH环境变量为：

PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
复制代码

再在当前项目下执行npm run env查看脚本运行时的环境变量，能够看到PATH环境变量为：

PATH=/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/Users/mac/Vue-projects/hao-cli/node_modules/.bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
复制代码

能够看到运行时的PATH环境变量多了两个路径：npm指令路径和项目中node_modules/.bin的绝对路径。

因此，经过npm run能够在不添加路径前缀的状况下直接访问当前项目node_modules/.bin目录里面的可执行文件。

PATH环境变量，是告诉系统，当要求系统运行一个程序而没有告诉它程序所在的完整路径时，系统除了在当前目录下面寻找此程序外，还应到哪些目录下去寻找。

用法指南

传入参数

关于scripts中的参数，这里要多说几句。网上有不少不是很准确的说法，通过本人的反复试验，node处理scripts参数其实很简单，好比：

"scripts": {
  "serve": "vue-cli-service serve",
  "serve1": "vue-cli-service --serve1",
  "serve2": "vue-cli-service -serve2",
  "serve3": "vue-cli-service serve --mode=dev --mobile -config build/example.js"
}
复制代码

除了第一个可执行的命令，以空格分割的任何字符串（除了一些shell的语法）都是参数，而且都能经过process.argv属性访问。

process.argv属性返回一个数组，这个数组包含了启动node进程时的命令行参数。第一个元素为启动node 进程的可执行文件的绝对路径名process.execPath，第二个元素为当前执行的JavaScript文件路径。剩余的元素为其余命令行参数。

好比执行npm run serve3命令，process.argv的具体内容为：

[ '/usr/local/Cellar/node/7.7.1_1/bin/node',
  '/Users/mac/Vue-projects/hao-cli/node_modules/.bin/vue-cli-service',
  'serve',
  '--mode=dev',
  '--mobile',
  '-config',
  'build/example.js']
复制代码

不少命令行包之因此这么写，都是依赖了 minimist 或者 yargs 等参数解析工具来对命令行参数进行解析。

以minimist对vue-cli-service serve --mode=dev --mobile -config build/example.js解析为例，解析后的结果为：

{ _: [ 'serve' ],
  mode: 'dev',
  mobile: true,
  config: 'build/example.js',
  '$0': '/Users/mac/Vue-projects/hao-cli/node_modules/.bin/vue-cli-service'}
复制代码

在./node_modules/.bin/vue-cli-service文件中能够看到minimist对命令行参数的处理：

const rawArgv = process.argv.slice(2)
const args = require('minimist')(rawArgv, {
  boolean: [
    // build
    'modern',
    'report',
    'report-json',
    'watch',
    // serve
    'open',
    'copy',
    'https',
    // inspect
    'verbose'
  ]
})
const command = args._[0]
service.run(command, args, rawArgv).catch(err => {
  error(err)
  process.exit(1)
})
复制代码

咱们还能够经过命令行传参的形式来进行参数传递：

npm run serve --params  // 参数params将转化成process.env.npm_config_params = true
npm run serve --params=123 // 参数params将转化成process.env.npm_config_params = 123
npm run serve -params  // 等同于--params参数

npm run serve -- --params  // 将--params参数添加到process.env.argv数组中
npm run serve params  // 将params参数添加到process.env.argv数组中
npm run serve -- params  // 将params参数添加到process.env.argv数组中
复制代码

多命令运行

有的项目在启动时可能须要同时执行多个任务，多个任务的执行顺序决定了项目的表现。

串行执行

串行执行，要求前一个任务执行成功之后才能执行下一个任务，使用&&符号来链接。

npm run script1 && npm run script2
复制代码

串行命令执行过程当中，只要一个命令执行失败，则整个脚本终止。

并行执行

并行执行，就是多个命令能够同时的平行执行，使用&符号来链接。

npm run script1 & npm run script2
复制代码

这两个符号是Bash的内置功能。此外，还可使用第三方的任务管理器模块：script-runner、npm-run-all、redrun。

env 环境变量

在执行npm run脚本时，npm会设置一些特殊的env环境变量。其中package.json中的全部字段，都会被设置为以npm_package_ 开头的环境变量。好比package.json中有以下字段内容：

{
  "name": "sh",
  "version": "1.1.1",
  "description": "shenhao",
  "main": "index.js",
  "repository": {
    "type": "git",
    "url": "git+ssh://git@gitlab.com/xxxx/sh.git"
  }
}
复制代码

能够经过process.env.npm_package_name 能够获取到package.json中name字段的值sh，也能够经过process.env.npm_package_repository_type获取到嵌套属性type的值git。

同时，npm相关的全部配置也会被设置为以npm_config_开头的环境变量。

此外，还会设置一个比较特殊的环境变量npm_lifecycle_event，表示正在运行的脚本名称。好比执行npm run serve 的时候，process.env.npm_lifecycle_event值为serve，经过判断这个变量，能够将一个脚本使用在不一样的npm scripts中。

这些环境变量只能在npm run的脚本执行环境内拿到，正常执行的node脚本是获取不到的。因此，不能直接经过env $npm_package_name的形式访问，但能够在scripts中定义脚本"scripts": {"bundle": "echo $npm_package_name"}来访问。

指令钩子

在执行npm scripts命令（不管是自定义仍是内置）时，都经历了pre和post两个钩子，在这两个钩子中能够定义某个命令执行先后的命令。

好比在执行npm run serve命令时，会依次执行npm run preserve、npm run serve、npm run postserve，因此能够在这两个钩子中自定义一些动做：

"scripts": {
  "preserve": "xxxxx",
  "serve": "vue-cli-service serve",
  "postserve": "xxxxxx"
}
复制代码

固然，若是没有指定preserve、postserve，会默默的跳过。若是想要指定钩子，必须严格按照pre和post前缀来添加。

上面提到过一个环境变量process.env.npm_lifecycle_event能够配合钩子来一块儿使用：

const event = process.env.npm_lifecycle_event

if (event === 'preserve') {
    console.log('Running the preserve task!')
} else if (_event === 'serve') {
    console.log('Running the serve task!')
}
复制代码

4. npm 配置

npm的配置操做能够帮助咱们预先设定好npm对项目的行为动做，也可让咱们预先定义好一些配置项以供项目中使用。因此了解npm的配置机制也是颇有必要。

优先级

npm能够从不一样的来源获取其配置值，按优先级从高到低的顺序排序：

命令行

npm run serve --params=123
复制代码

执行上述命令时，会将配置项params的值设为123，经过process.env.npm_config_params能够访问其配置值。这个时候的params配置值将覆盖全部其余来源存在的params配置值。

env 环境变量

若是env环境变量中存在以npm_config_为前缀的环境变量，则会被识别为npm的配置属性。好比在env环境变量中设置npm_config_package_lock变量：

export npm_config_package_lock=false // 修改的是内存中的变量，只对当前终端有效
复制代码

这时候执行npm install，npm会从环境变量中读取到这个配置项，从而不会生成package-lock.json文件。

查看某个环境变量：echo $NODE_ENV

删除某个环境变量：unset NODE_ENV

npmrc 文件

经过修改 npmrc 文件能够直接修改配置。系统中存在多个npmrc文件，这些npmrc文件被访问的优先级从高到低的顺序为：

• 项目级的.npmrc文件

  只做用在本项目下。在其余项目中，这些配置不生效。经过建立这个.npmrc文件能够统一团队的npm配置规范。

• 用户级的.npmrc文件

  mac下的地址为~/.npmrc。（npm config get userconfig能够看到存放的路径）

• 全局级的npmrc文件

  mac下的地址为$PREFIX/etc/npmrc。（npm config get globalconfig能够看到存放的路径）

• npm内置的npmrc文件

  这是一个不可更改的内置配置文件，为了维护者以标准和一致的方式覆盖默认配置。mac下的地址为/path/to/npm/npmrc。

.npmrc参照 npm/ini 格式编写。

默认配置

经过npm config ls -l查看npm内部的默认配置参数。若是命令行、环境变量、全部配置文件都没有配置参数，则使用默认参数值。

npm config 指令

npm提供了几个 npm config 指令来进行用户级和全局级配置：

set

npm config set <key> <value> [-g|--global]
npm config set registry <url>  # 指定下载 npm 包的来源，默认为 https://registry.npmjs.org/ ，能够指定私有源

npm config set prefix <path>  # prefix 参数指定全局安装的根目录
# 配置 prefix 参数后，当再对包进行全局安装时，包会被安装到以下位置：
# Mac 系统：{prefix}/lib/node_modules
# Windows 系统：{prefix}/node_modules
# 把可执行文件连接到以下位置：
# Mac 系统：{prefix}/bin
# Windows 系统：{prefix}
复制代码

使用-g|--global标志修改或新增全局级配置，不使用的话修改或者新增用户级配置（相应级别的.npmrc文件会更新）。

若是key不存在，则会新增到配置中。若是省略value，则key会被设置成true。

还能够覆盖package.json中config字段的值：

// package.json
{
  "name" : "foo",
  "config" : { "port" : "8080" },
  "scripts" : { "start" : "node server.js" }
}
复制代码

// server.js
console.log(process.env.npm_package_config_port)  // 打印8080
复制代码

执行指令：

npm config set foo:port 8000
复制代码

// server.js
console.log(process.env.npm_package_config_port)  // 打印8000
复制代码

get

npm config get <key>
npm config get prefix  # 获取 npm 的全局安装路径
复制代码

按照配置优先级，获取指定配置项的值。

delete

npm config delete <key>
复制代码

npm官网上说能够删除全部配置文件中指定的配置项，但经实验没法删除项目级的.npmrc文件里指定的配置项。

list

npm config list [-l] [--json]
复制代码

加上-l或者--json查看全部的配置项，包括默认的配置项。不加的话，不能查看默认的配置项。

edit

npm config edit [-g|--global]
复制代码

在编辑器中打开配置文件。使用-g|--global标志编辑全局级配置和默认配置，不使用的话编辑用户级配置和默认配置。

参考 npm config 来获取更多的默认配置。

5. npm 工程管理

项目版本号管理

package.json中的version字段表明的是该项目的版本号。每当项目发布新版本时，须要将version字段进行相应的更新以便后期维护。虽然能够手动的修改vsersion字段，可是为了整个发布过程的自动化，尽可能使用 npm version 指令来自动更新version：

npm version (v)1.2.3  # 显示设置版本号为 1.2.3 
npm version major  # 大版本号加 1，其他版本号归 0
npm version minor  # 小版本号加 1，修订号归 0
npm version patch  # 修订号加 1
复制代码

显示的设置版本号时，版本号必须符合semver规范，容许在版本号前加上个v标识。

若是不想让这次更新正式发布，还能够建立预发布版本：

# 当前版本号为 1.2.3
npm version prepatch  # 版本号变为 1.2.4-0，也就是 1.2.4 版本的第一个预发布版本
npm version preminor  # 版本号变为 1.3.0-0，也就是 1.3.0 版本的第一个预发布版本
npm version premajor  # 版本号变为 2.0.0-0，也就是 2.0.0 版本的第一个预发布版本
npm version prerelease  # 版本号变为 2.0.0-1，也就是使预发布版本号加一
复制代码

在git环境中，执行npm version修改完版本号之后，还会默认执行git add->git commit->git tag操做：

其中commit message默认是自动修改完的版本号，能够经过添加-m/--message选项来自定义commit message：

npm version xxx -m "upgrade to %s for reasons"  # %s 会自动替换为新版本号
复制代码

好比执行npm version minor -m "feat(version): upgrade to %s for reasons"后：

若是git工做区还有未提交的修改，npm version将会执行失败，能够加上-f/--force后缀来强制执行。

若是不想让npm version指令影响你的git仓库，能够在指令中使用--no-git-tag-version参数：

npm --no-git-tag-version version xxx
复制代码

若是想默认不影响你的git仓库，能够在npm设置中禁止：

npm config set git-tag-version false  # 不自动打 tag
npm config set commit-hooks false     # 不自动 commit
复制代码

模块 tag 管理

不常常发布包的同窗可能对模块 tag 概念不是很清楚。以vue为例，首先执行npm dist-tag ls vue查看vue包的tag：

beta: 2.6.0-beta.3
csp: 1.0.28-csp
latest: 2.6.10
复制代码

上面列出的beta、csp、latest就是tag。每一个tag对应了一个版本。

那tag到底有什么用呢？tag相似于git里面分支的概念，发布者能够在指定的tag上发布版本，而使用者能够选择指定的tag来安装包。不一样的标签下的版本之间互不影响，这在发布者发布预发布版本包和使用者尝鲜预发布版本包的同时，不影响到正式版本。

在发布包的时候执行npm publish默认会打上latest这个tag，其实是执行了npm publish --tag latest。而在安装包的时候执行npm install xxx则会默认下载latest这个tag下面的最新版本，其实是执行了npm install xxx@latest。固然，咱们也能够自定义tag：

# 当前版本为1.0.1
npm version prerelease  # 1.0.2-0
npm publish --tag beta
npm dist-tag ls xxx  # # beta: 1.0.2-0
npm install xxx@beta  # 下载beta版本 1.0.2-0
复制代码

当prerelease版本已经稳定了，能够将prerelease版本设置为稳定版本：

npm dist-tag add xxx@1.0.2-0 latest
npm dist-tag ls xxx  # latest: 1.0.2-0
复制代码

域级包管理

细心的同窗会发现，在package.json中的依赖有两种形式：

"devDependencies": {
  "@commitlint/cli": "^7.2.1",
  "commitizen": "^3.0.4"
}
复制代码

其中以@开头的包名，是一个域级包（scoped package），这种域级包的做用是将一些packages集中在一个命名空间下，一方面能够集中管理，一方面能够防止与别的包产生命名冲突。

要发布域级包，首先要在项目的package.json的name属性中添加scope相关的声明，能够经过指令添加：

npm init --scope=scopeName -y
复制代码

package.json变为：

{
  "name": "@scopeName/package"
}
复制代码

能够将用户名做为域名，也能够将组织名做为域名。

因为用@声明了该包，npm会默认将此包认定为私有包，而在npm上托管私有包是须要收费的，因此为了不发布私有包，能够在发布时添加--accss=public参数告知npm这不是一个私有包：

npm publish --access=public
复制代码

域级包不必定就是私有包，可是私有包必定是一个域级包。

同时，在安装域级包时须要按照域级包全名来安装：

npm install @scopeName/package
复制代码

6. npm 的几个实用技巧

默认初始化配置

使用npm init初始化一个新的项目时会提示你去填写一些项目描述信息。若是以为填写这些信息比较麻烦的话，可使用-y标记表示接受package.json中的一些默认值：

npm init -y
复制代码

也能够设置初始化的默认值：

npm config set init-author-name <name> -g
npm config set init-author-email <email> -g
复制代码

上面两条指令为你的npm设置了默认的做者名和邮箱，当执行npm init -y的时候，package.json中的做者姓名和邮箱字段就会自动写入预设的值。

查看脚本命令

查看当前项目的全部npm脚本命令最直接的办法就是打开项目中的package.json文件并检查scripts字段。咱们还可使用不带任何参数的npm run命令查看：

npm run
复制代码

查看环境变量

经过env查看当前的全部环境变量，而查看运行时的全部环境变量能够执行：

npm run env
复制代码

检查环境

能够经过npm doctor命令在咱们的环境中运行多个检查。好比，检查咱们当前的环境是否可以链接到npm服务、检查node和npm版本、检查npm源、检查缓存文件的权限等：

npm doctor
复制代码

模块管理

检查当前项目依赖的全部模块，包括子模块以及子模块的子模块：

npm list/ls
复制代码

若是还想查看模块的一些描述信息（package.json中的description中的内容）：

npm la/ll // 至关于npm ls --long
复制代码

一个项目依赖的模块每每不少，能够限制输出模块的层级来查看：

npm list/ls --depth=0 // 只列出父包依赖的模块
复制代码

检查项目中依赖的某个模块的当前版本信息：

npm list/ls <packageName>
复制代码

查看某个模块包的版本信息：

npm view/info <packageName> version // 模块已经发布的最新的版本信息（不包括预发布版本）
npm view/info <packageName> versions // 模块全部的历史版本信息（包括预发布版本）
npm view/info <packageName> <package.json中的key值> // 还能查看package.json中字段对应的值
复制代码

查看一个模块究竟是由于谁被安装进来的，若是显示为空则代表该模块为内置模块或者不存在：

npm ll <packageName>
复制代码

查看某个模块的全部信息，包括它的依赖、关键字、更新日期、贡献者、仓库地址和许可证等：

npm view/info <packageName>
复制代码

查看当前项目中可升级的模块：

npm outdated
复制代码

整理项目中无关的模块：

npm prune
复制代码

查看模块文档

打开模块的主页：

npm home <packageName> 
复制代码

打开模块的代码仓库：

npm repo <packageName> 
复制代码

打开模块的文档地址：

npm docs <packageName>
复制代码

打开模块的 issues 地址：

npm bugs <packageName>
复制代码

在不一样的目录下运行脚本

你的文件夹中确定存在不少应用程序，而当你想要启动某个应用程序时，确定是经过cd指令一步步进入到你所想要启动的应用程序目录下，而后再执行启动命令。npm提供了--prefix能够指定启动目录：

npm run dev --prefix /path/to/your/folder
复制代码

本地开发模块调试

1. 假设你开发的是一个全局命令行模块A，这时候你须要本地调试它，而不但愿每次都npm publish模块，而后安装调试。这个时候你能够在模块的目录下执行：

npm link
复制代码

上述命令经过连接目录和可执行文件，实现任意位置的npm模块命令的全局可执行。执行完上述命令后，就能够全局调用A命令了。

npm link主要作了两件事：

1. 为目标npm模块建立软连接，将其连接到全局node模块安装路径/usr/local/lib/node_modules/。
2. 为目标npm模块的可执行bin文件建立软连接，将其连接到全局node命令安装路径/usr/local/bin/。

2. 假设你开发的是一个功能模块B，而后你在项目C中调试它，固然你能够将该模块的代码拷贝到须要项目C中调试，但这也不是理想的方法，能够执行以下操做：

# 项目 B 中
npm link

# 项目 C 中
npm link B
复制代码

上述命令为功能模块B在全局建立一个软连接，而后将其连接到项目C模块安装路径./node_modules/，等同于生成了本地模块的符号连接。而后，咱们就能够在项目C中加载该模块：

// 项目 C 中
const B = require('B')
复制代码

全部对模块B的修改，都会直接反映在项目C中。当你的项目再也不须要该模块的时候，须要解除软链接，不然当你在项目中安装npm上的包时将会出错：

# 项目 C 中
npm unlink B

# 项目 B 中
npm unlink
复制代码

安全漏洞检查

检查项目中是否存在具备安全漏洞的依赖包，若是存在，则将生成其漏洞报告显示在控制台中：

npm audit [--json]  # 加上--json，以 JSON 格式生成漏洞报告
复制代码

npm升级到6.x版本之后，在项目中更新或者下载新的依赖包之后会自动执行 npm audit 命令，对项目依赖包进行安全检查，若是存在安全漏洞，将生成漏洞报告并在控制台中显示。

修复存在安全漏洞的依赖包（自动更新到兼容的安全版本）：

npm audit fix
复制代码

执行npm audit fix能修复大部分存在安全漏洞的依赖包，对于一些没能自动修复漏洞的依赖包，说明出现了SERVER WARNING之类的警告（主要发生在依赖包更改了不兼容的api或者大版本作了升级的状况下），这意味着推荐的修复版本还可能出现问题，这时能够执行以下命令来修复这些依赖包：

npm audit fix --force
复制代码

--force会将依赖包版本号升级到最新的大版本，而不是兼容的安全版本。大版本的升级可能会出现一些不兼容的用法，因此尽可能避免使用--force。

若是执行npm audit fix --force后仍是存在有安全漏洞的依赖包，手动执行npm audit打印出还存在安全漏洞的依赖包的具体信息，其中More info对应的连接中可能给出了解决方案。

若是想知道audit fix会怎么处理项目中的依赖包，能够预先查看：

npm audit fix --dry-run --json
复制代码

若是只想修复生产环境的依赖包（只更新dependencies中的依赖包，不更新devDependencies中的依赖包）：

npm audit --only=prod
复制代码

若是不想修复依赖包，只修改package-lock.json文件：

npm audit fix --package-lock-only
复制代码

若是想安装某个包时不进行安全漏洞检查：

npm install packageName --no-audit
复制代码

要想安装全部包时都不进行安全漏洞检查，则能够修改npm配置：

npm config set audit false
复制代码

依赖锁定

npm默认安装模块时，会经过脱字符^来限定所安装模块的主版本号。能够配置npm经过波浪符~来限定安装模块版本号：

npm config set save-prefix="~"
复制代码

固然还能够配置npm仅安装精确版本号的模块：

npm config set save-exact true
复制代码

在持续集成环境中安装包

在持续集成环境中建议使用npm ci来代替npm install：

npm ci
复制代码

它与npm install之间的主要区别是：

• 要求项目中必须具备package-lock.json或 npm-shrinkwrap.json，不然执行npm ci将会报错。
• 若是检测到package.json和package-lock.json中的依赖项不匹配的话，npm ci将退出并报错，而不是更新两个文件中的版本号。
• npm ci只根据package-lock.json来安装包，而npm install在安装的过程当中会结合package.json和package-lock.json来计算依赖包版本的差别性问题。因此相比较npm install，npm ci既能提高包的安装速度，又能避免在生产化境中出现包版本不一致的问题。
• 若是项目中已经存在node_modules，npm ci将会先删除它，而后再安装。
• npm ci只能一次安装整个项目的依赖包，而不能为项目安装单个依赖包。

7. npm 包发布

准备工做

在你为你的包搭建了一个开发构建环境（这里不作详细说明）后，有两点须要注意：

1. 在package.json文件的main字段中配置引入包的入口文件，通常配置打包后的文件路径。

{
    "main": "./lib/index.js",
}
复制代码

2. 在包的根目录新建.npmignore文件，来指定包的哪几个文件夹不须要被发布。

.idea
node_modules
src
test
.eslintignore
.eslintrc
复制代码

发布流程

1. 若是没有npm帐号，先注册个帐号；
2. 进入到项目的根目录下，执行npm login，而后根据提示输入用户名、密码；
3. 执行npm publish发布，发布成功后，你的npm包就能够在npm官网上检索到了；
4. 撤回发布的版本，能够执行npm unpublish packageName@x.x.x。

发布常见的报错

• 400：版本问题，修改package.json的version便可；
• 401：npm源设置成第三方源的时候发生的，好比咱们常常会将镜像源设置成淘宝源。只要把镜像源改回默认的便可；
• 403：包名重复，修改包名从新发布便可。

发布一个支持 tree shaking 机制的包

tree shaking是依赖ES Module的模块特性来工做的，那是由于ES Module模块的依赖关系是在编译时肯定的（和运行时无关），而且以后不能再改变，因此基于此特性能够进行可靠的静态分析。

而一般，咱们开发的npm包为了更好的兼容浏览器，会借助babel将代码进行兼容性转译，而其中用的最频繁的@babel/preset-env预设中包含了ES2015 modules to CommonJS transform 的插件，这个插件的做用会将ES Module语法转换成CommonJS语法，这样就失去了ES Module的特性，也就致使没法tree shaking。

那咱们直接把package.json中的main字段指向ES6语法的文件不就行了吗？这样会带来两个问题：

1. babel默认会忽略node_modules中的文件来提升编译速度，若是想要把你的ES6语法的包向后兼容，则须要给项目中的babel配置复杂的屏蔽规则，从而将你的包加入到白名单中。
2. 若是在nodejs环境中使用你的包，而且恰巧nodejs环境中不支持ES Module规范，那么就会致使代码报错。

为了解决以上问题，咱们须要在package.json中增长两个配置项。

module

该字段指向一个既符合ES Module模块规范可是又使用ES5语法的源文件。这么作的目的是为了启动tree shaking的同时，又避免代码兼容性的问题。

{
    "main": "./lib/index.js", // 指向 CommonJS 模块规范的代码入口文件
    "module": "./lib/index.es.js" // 指向 ES Module 模块规范的代码入口文件
}
复制代码

如上配置要求你的包中要发布两种模块规范的版本。若是你的npm环境支持module字段，则会优先使用ES Module模块规范的入口文件，若是不支持则会使用CommonJS模块规范的入口文件。

sideEffects

该字段表示你的npm包是否有反作用。具体点就是，当该字段设为false时，代表这个包时没有反作用的，能够应用tree shaking；若是为数组时，数组的每一项表示的是有反作用的文件，这些文件将不会应用tree shaking。

{
  "sideEffects": [
    "dist/*",
    "es/components/**/style/*",
    "lib/components/**/style/*",
    "*.less"
  ]
}
复制代码

其实要想发布一个支持tree shaking机制的包，最主要是要构建出一个符合module字段要求的源文件，也就是一个既符合ES Module模块规范可是又采用ES5语法的源文件。

rollup能够直接构建出符合ES Module模块规范的文件，可是webpack不能。因此咱们只须要使用rollup提供的构建能力，在配置文件中把output的格式设置为es便可：

// rollup.config.js
export default {
  ...,
  output: {
    file: 'bundle.es.js',
    format: 'es'
  }
}
复制代码

为了更好地使用ES Module模块规范来开启tree shaking功能，优先选用rollup来开发npm包。

8. 最后

关于npm的知识点暂时总结到这里，可能还有不少方面没有总结到位，后续若是还有新的知识点会随时更新，也欢迎各位大佬们随时来补充，共同进步！