uni-app是一个广泛的产品，支持多个开发ide、HBuilderX的正式版和alpha版、cli和普通项目、许多终端，云软件包APP和本地软件包APP以及编译器模式都是旧的样板模式
它们都将升级。 如果一个已升级，另一个未升级，则可能会发生异常。
通常，升级HBuilderX时，附带的基于app运行的、uni-app编译器和云打包支持引擎将同步升级。 但是，如果开发人员使用cli创建项目、使用自定义基础并使用5 sdk脱机打包，则必须手动维护版本更新。
我们经常遇到的误报问题是：“我的HBuilderX已经是最新版了。 升级日志中列出的已解决问题为什么还不存在？ ”。 实际上，这是因为在cli项目下编译器旧，本地打包的sdk旧，以及基于自定义的版本旧。
如果使用cli创建项目，即项目的根目录为package.json，则无论使用的是哪个ide，还是使用的是HBuilderX，cli项目的编译器都位于项目下面需要手动NPM更新才能升级编译器。 以及预编译器(如less和scss )的安装，也必须自己安装npm并在项目下安装，而不是HBuilderX插件管理。
如果使用脱机软件包，请注意，在HBuilderX升级后，基于生产的和云包的引擎将跟踪HBuilderX升级，而sdk必须手动升级。 sdk的版本升级一般比HBuilderX正式版的升级晚一两天。 在这里下载最新版
如果使用自定义基础，则以前创建的自定义基础不会跟随HBuilderX升级。 升级HBuilderX后，应该重新创建新的自定义基础。
如果使用wgt升级，则使用较新版本的HBuilderX编译的wgt将在以前的运行时运行。 在确认是否存在兼容性问题之前需要进行测试。 如果有问题，不要升级wgt，整个升级。
出于向后兼容性的考虑，uni-app编译器升级到新的自定义组件模式后，保持了与旧编译模式的向后兼容性。
在hbuilderx alpha版中，App端始终使用新编译器，并忽略manifest配置。
在HBuilderX正式版中，新创建的项目使用新编译器。 旧项目不是强制使用，而是由开发人员自己设置为在manifest中打开。
使用其他ide开发uni-app时，经常会因为单词拼写错误而执行失败。 使用webpack进行编译时，许多错误不直观，调试时间也很长。 请不要依赖从一开始就有很好提示的HBuilderX来拼错单词。
云封装的引擎版本说明
Hbuilderx阿尔法，云包机只有一套。 无论hbuilderx alpha的版本如何，支持的打包机始终是最新的alpha客户端引擎。
HBuilderX的正式版有两套打包机，一套是最新的正式版，一套是下一个新的正式版。
中间的紧急更新版本没有独立包装机。
举个例子：
HBuilderX有几个正式版本：1.8.0、1.8.1、1.8.2、1.9.0和1.9.1。
那么，目前可用的打包机有1.9.1和1.8.2两台。 即每个主版本的最后一个版本)
除了这两个HBuilderX版本之外，所有其他版本的云打包都指向支持最新版本1.9.1的打包机。 (也就是说，云包机只剩下两个大版本)
很多人在报告问题时不说清楚自己的情况，让别人回答错误。
很多人在找问题的时候没有看到条件，所以用了不适合自己的错误方案。
为了减少问题，建议使用HBuilderX完成所有任务，包括创建项目、运行编译和在云中打包app。
因为在这个系统中，政府会注意和引导很多常见问题，减少问题的概率。 随着HBuilderX的升级，uni-app编译器、基于实际运行的和云包引擎将被升级。
版本列表
uni-app开发中各产品的版本对应表如下所示。