uni-app是一个跨度很大的产品，支持多种开发ide、HBuilderX有正式版和alpha版、支持cli和普通项目、支持很多端、有云打包app和本地打包app、编译器模式支持老的模板模式和新的自定义组件模式。它们都会升级，如果出现一个升级、另一个未升级的情况，可能会运行异常。
正常情况，HBuilderX升级后，其自带的app运行基座、uni-app编译器、云打包配套引擎会同步升级。但在开发者使用cli创建项目、使用自定义基座、使用5+sdk离线打包时，就需要手动维护版本更新。
我们经常遇到的误报问题是：“我的HBuilderX已经是最新版了，升级日志里提到的已解决问题，为什么没有仍然存在？”，其实有的是因为cli项目下编译器是旧的、有的是因为本地打包的sdk是旧的，有的是因为自定义基座的版本是旧的。
如果你使用cli创建项目（即项目根目录是package.json），不管用什么ide，即便是用HBuilderX，切记cli项目的编译器是在项目下的，HBuilderX不管怎么升级都不会影响编译器版本。你需要手动npmupdate来升级编译器。以及如果你想要安装less、scss等预编译器，也需要自己npm安装在项目下，而不是在HBuilderX的插件管理里安装。
如果你使用离线打包，请注意HBuilderX升级后，真机运行基座和云打包对应引擎跟随HBuilderX升级，而你的sdk需要手动升级。sdk的版本升级一般滞后HBuilderX正式版升级一两天。在这里下载最新版本
如果你使用自定义基座，之前制作的自定义基座是不会跟随HBuilderX升级的，升级HBuilderX后你应该重新制作新版自定义基座。
如果你使用wgt升级，新版HBuilderX编译的wgt，运行到之前的runtime上，一定要先测试好，看有没有兼容性问题。如果有问题，就不要wgt升级，整包升级。
考虑到向下兼容，uni-app编译器在升级为新的自定义组件模式后，同时保留了对老编译模式的向下兼容。在HBuilderXalpha版中，App端一定会使用新编译器，不理会manifest配置。在HBuilderX正式版中，新创建的项目会使用新编译器，老项目不会强制使用，而是开发者自己在manifest里配置开启。
如果你使用其他ide开发uni-app，会经常因为拼错单词而运行失败，因为经过webpack编译一道，很多错误反应的不够直观，排错时间很长，不如从开始就依赖有良好提示的HBuilderX，避免敲错单词。
打包的引擎版本说明HBuilderXAlpha，只有1套云打包机，不管你的HBuilderXalpha版本多少，对应的打包机一定是最新的alpha版的客户端引擎。HBuilderX正式版，有2套打包机，一个是最新正式版，一个是次新正式版。中间的紧急更新版本没有独立打包机。举个例子：HBuilderX有1.8.0、1.8.1、1.8.2、1.9.0、1.9.1这几个正式版。那么当前可用的打包机有1.9.1和1.8.2这2台。（即每个大版本的最后一个版本）除了这2个HBuilderX版本外，其他版本的云打包都指向最新的1.9.1版对应的打包机。（即只保留2个大版本的云打包机）
很多人在报问题时不说清楚自己的情况，导致别人给出错误的回答。很多人在搜问题时没注意看条件，导致使用了并不适用于自己的错误方案。
要想问题少，推荐使用HBuilderX完成一切工作，包括创建项目、运行编译、云打包app。因为在这套体系里，官方会对很多常见的问题做出提醒和引导，减少问题的概率。随着HBuilderX的升级，uni-app编译器、真机运行基座、云打包引擎都会升级。
#互联网#