基本概念就不多说了，主要是想在项目中，使用“范围”控制的优势，写了一个依赖版本号之后，未来依赖包升级可以不需要手动升级该版本号，可自动安装最新兼容版本。

常规兼容

常规情况下，需要掌握 ^, ~, x, - 这几个版本控制符即可。例如 ^1.0.0 相当于 1.x，~1.1.0 相当于 1.1.x。

实验阶段的包

版本号以 0 开头的包都是实验阶段的。例如 0.0.1, 0.1.0 这种包都是处于实验阶段，还为发布正式版本，因此，在正式环境使用时要小心。基于这种情况，我建议直接写死版本号，而不要采用 ^ 或 ~，因为你怎么知道新加的实验功能是否符合你的预期。

当然，纯理论探讨，实验阶段的包也可以 ^ 或 ~，但是相对而言，全部降一位。例如 ^0.1.0 可以兼容 0.1.1 版本，但不兼容 0.2.0 版本。如果 ~0.0.1，相当于没写 ~。

Prerelease

和实验阶段包又不同，它处于预发布阶段。比如在发布 3.0.0 之前，可能需要公测一段时间，各种修 bug。但理论上，prerelease 相当于正式版的实验阶段。

对于 prerelease 版本而言，前面的常规方案和实验阶段常规方案，都不包含 prerelease 版本，也就是说 ^3.0.0 并不包含 3.1.0-alpha.1。但是反过来，3.1.0-alpha.1 属于 3.1.0 的一部分，用一个比喻来类比：A-, A, A+ 都属于 A 等。但是 ~A, ^A 都只包含 A, A+ 而不包含 A-，类比数学上的概念，就是复数中虚数部分。

那么怎么控制 prerelease 的范围呢？

^3.0.0-alpha 将包含 3.0.0-alpha.0, 3.0.0-beta.0, 3.0.0-rc, 3.0.0, 3.1.0...，但不包含 3.1.0-alpha.x。也就是说，^ 或 ~ 可以包含所指示的版本的 prerelease 版本，以及兼容该版本的高版本（不含高版本的 prerelease 版本）。

升级 prerelease 可以使用 npm version prerelease 进行升级。

两个 prerelease 版本号谁的版本更高呢？prerelease 末尾版本号部分纯粹以字母顺序进行排序，因此 rc > beta > alpha，而且，由于纯粹按字母排序，所以没有 alpha.x 这种使用 x 的表示方法。因此，如果要控制为只包含 prerelease 的版本，没有直接的办法，只能使用 >=3.0.0-alpha <3.0.0-beta 这种表示方法。