postcss-px-to-viewport 在服务端部署时失效
问题：
Nuxt 搭建的移动 web 项目，本地开发时 postcss-px-to-viewport 单位转换功能正常，发布到测试环境服务器时失效。
环境：
本地：
node：14.7.0
npm：6.14.7
cnpm：6.1.1
postcss：自动安装
postcss-px-to-viewport：1.1.1（自动安装最新版）
服务器：
node：14.15.5
npm：6.14.13
cnpm：6.1.1
postcss：自动安装
postcss-px-to-viewport：1.1.1（自动安装最新版）
原因：
该插件依赖 postcss，如果不显式安装，则会安装最新版本，版本过高导致插件失效。
postcss-px-to-viewport 依赖声明：
"dependencies": {
"postcss": ">=5.0.2"
},
但是实际情况，我这里安装的 postcss 是 7.x 版本，版本过高，不兼容。
解决方案：
在 package 中显示指定要安装的 postcss 版本，具体什么版本要看插件的依赖声明（插件的 package.json 文件中有声明）。我的项目指定安装 6.x 版本的 postcss 可以解决上述问题。
"postcss":"~6.0.0",
拓展知识
package 依赖声明的版本号前的符号是什么意思
~ 会匹配最近的小版本依赖包，比如~1.2.3会匹配所有1.2.x版本，但是不包括1.3.0
^ 会匹配最新的大版本依赖包，比如^1.2.3会匹配所有1.x.x的包，包括1.3.0，但是不包括2.0.0
* 这意味着安装最新版本的依赖包
npm install 到底做了什么
作者：Roscoe
链接：https://www.zhihu.com/question/66629910/answer/273992383
来源：知乎
输入 npm install 命令并敲下回车后，会经历如下几个阶段（以 npm 5.5.1 为例）：
执行工程自身 preinstall
当前 npm 工程如果定义了 preinstall 钩子此时会被执行。
确定首层依赖模块
首先需要做的是确定工程中的首层依赖，也就是 dependencies 和 devDependencies 属性中直接指定的模块（假设此时没有添加 npm install 参数）。工程本身是整棵依赖树的根节点，每个首层依赖模块都是根节点下面的一棵子树，npm 会开启多进程从每个首层依赖模块开始逐步寻找更深层级的节点。
获取模块
获取模块是一个递归的过程，分为以下几步：
- 获取模块信息。在下载一个模块之前，首先要确定其版本，这是因为 package.json 中往往是 semantic version（semver，语义化版本）。此时如果版本描述文件（npm-shrinkwrap.json 或 package-lock.json）中有该模块信息直接拿即可，如果没有则从仓库获取。如 packaeg.json 中某个包的版本是 ^1.1.0，npm 就会去仓库中获取符合 1.x.x 形式的最新版本。
- 获取模块实体。上一步会获取到模块的压缩包地址（resolved 字段），npm 会用此地址检查本地缓存，缓存中有就直接拿，如果没有则从仓库下载。
- 查找该模块依赖，如果有依赖则回到第1步，如果没有则停止。
模块扁平化（dedupe）
上一步获取到的是一棵完整的依赖树，其中可能包含大量重复模块。比如 A 模块依赖于 loadsh，B 模块同样依赖于 lodash。在 npm3 以前会严格按照依赖树的结构进行安装，因此会造成模块冗余。
从 npm3 开始默认加入了一个 dedupe 的过程。它会遍历所有节点，逐个将模块放在根节点下面，也就是 node-modules 的第一层。当发现有重复模块时，则将其丢弃。
这里需要对重复模块进行一个定义，它指的是模块名相同且 semver 兼容。每个 semver 都对应一段版本允许范围，如果两个模块的版本允许范围存在交集，那么就可以得到一个兼容版本，而不必版本号完全一致，这可以使更多冗余模块在 dedupe 过程中被去掉。
比如 node-modules 下 foo 模块依赖 lodash@^1.0.0，bar 模块依赖 lodash@^1.1.0，则 ^1.1.0 为兼容版本。
而当 foo 依赖 lodash@^2.0.0，bar 依赖 lodash@^1.1.0，则依据 semver 的规则，二者不存在兼容版本。会将一个版本放在 node_modules 中，另一个仍保留在依赖树里。
举个例子，假设一个依赖树原本是这样：
node_modules
-- foo
---- lodash@version1
-- bar
---- lodash@version2
假设 version1 和 version2 是兼容版本，则经过 dedupe 会成为下面的形式：
node_modules
-- foo
-- bar
-- lodash（保留的版本为兼容版本）
假设 version1 和 version2 为非兼容版本，则后面的版本保留在依赖树中：
node_modules
-- foo
-- lodash@version1
-- bar
---- lodash@version2
安装模块
这一步将会更新工程中的 node_modules，并执行模块中的生命周期函数（按照 preinstall、install、postinstall 的顺序）。
执行工程自身生命周期
当前 npm 工程如果定义了钩子此时会被执行（按照 install、postinstall、prepublish、prepare 的顺序）。
最后一步是生成或更新版本描述文件，npm install 过程完成。