先回答标题的提问“有了package.json文件package-lock.json还有用吗？”。 答案是肯定的，而且是必须的。说到这，就不得不说说 package.json 配置：
package-lock.json 是为了弥补 package.json 配置的不足。
以下是 package.json 的配置内容：
从图中可以看得出，这里配置了各个依赖包以及它的版本号，但需要注意的：每个版本号都有一个前缀：“^” / “~” ，那这两种不同的前缀分别有什么含义呢？
首先，可以明确的一点是，这两种前缀肯定是对当前版本的一个修饰（版本限制）。
“^”：是对 “主版本” 的限制，表示只要主版本保持一致即可，eg：^1.2.0 表示 1.2.0(包括本身) 到 2.0.0(不包括本身)之前的所有版本都行。
“~”：是对 “次版本” 的限制，表示只要次版本保持一致即可，eg：~1.2.0 表示 1.2.0(包括本身) 到 1.3.0(不包括本身)之前的所有版本都行。
有了以上的基础，就可以看的出，在 package.json 中存在大量的不精确版本的依赖，这也导致了不同版本之间的差异导致开发中可能会出现意想不到的问题。
问题一：为什么会有这么多不确定的依赖呢？
答：在我们初次创建项目时，我们可能并不需要太关注某个依赖包的版本。只要满足大版本一致即可开发。所以 package.json 中就为依赖包添加了 “^” 的版本限制。
问题二：有了版本限制不就好了吗，为什么还 package-lock.json ?
答：为了更加的精确匹配初次安装的依赖包，防止意料之外的错误。
- 执行 npm i 时，相当于发送一个请求，我们在请求前依据 package.json 的版本限制，发送的参数就是只要大版本一致随便给我一个包就行，此时是不确定的一个版本(这个是随官方版本更新自动获取当前版本最新的包)！在npm响应我们的请求后，这个依赖包的版本就确定了，是一个精确版本的依赖包。
- 之后我们就建立在这个依赖包的基础上开发。如果没有保存依赖的精确版本，那我们在团队合作开发时，可能团队中每个开发者安装的版本都不一样，虽说小版本问题不大，但多多少少都会有差异吧。特别是存在大量的依赖包时，这种差异会无限放大，因此，我们必须保证团队搜友开发者安装的版本都是一致的。这样一来，就需要有一个专门的文件来记录依赖的精确版本信息。
package-lock.json 从哪来的，有什么用？
package-lock.json文件是在我们执行 npm i 时自动生成的，是用于记录我们开发时实际安装的包的来源和精确版本以及其依赖(依赖包的依赖)。
作用：锁定项目依赖包的精确版本。
package-lock.json 文件的属性解释：
| 属性名 | 描述 |
|---|---|
| name | 包锁（package-lock）的名称，用于匹配对应的 package.json |
| version | 包锁的版本，用于匹配对应的 package.json |
| lockfileVersion | 整数版本，从1开始，包含此文档的版本号，生成此package-lock.json时使用的语义 |
| requires | 这是一个模块名称到版本的映射。这是这个模块所需的所有内容的列表，不管它将安装在哪里，版本应该通过普通匹配规则进行匹配。 |
| dependencies | 依赖，指定该项目所依赖的包(这里列出了所有项目依赖包以及依赖包自己的依赖) |
小结
package-lock.json 配置文件对版本控制的作用还是非常重要的，特别是在团队合作过程中，千万别觉得没用或为了冲突处理方便就随意移除这个文件。
- 上面小结提到一个出现冲突的问题，这里再多说以一下。
一般情况下，这个配置文件是不会出现冲突的，如果有冲突的出现，就说明，两个人在提交代码前安装了 之前不存在 的相同包相同版本，或者安装了相同包不同的版本。
情况一（相同包相同版本）：如果之前package-lock.json 文件里不存在这个包(即添加新的依赖包)，则会自动创建一个，此时两个人各自在本地创建，然后提交。此时一定会出现冲突。
解决办法： 选择性的保留任意一个即可（这里建议，最好的实现是仅有一个人添加新的包即可，团队其他开发者拉取最新的代码后直接执行 npm i 即可）。
情况二（相同包不同版本）：一个开发者自己升级依赖到指定的版本，另一位开发者，不知情的情况下又做了新的升级，两次升级的版本并不一致。此时提交一定会出现冲突。
解决办法： 开发者自行沟通，明确好要更新的版本，重新安装，再次提交。