前言
uni-app是一个很牛逼的开发框架，这是没错的，但是，正是因为它兼顾H5、小程序、生成原生app，所以它又存在很多的不足，这里就讨论一下。
你在用uni-app开发什么？
uni-app主要用途我认为只有两个：
- 开发微信小程序
- 开发原生APP
鸡肋用途是：
- 开发H5：Vue CLI不香么？干嘛要用uni-app呢？
- 开发其他小程序：需求少，当然，如果一定要开发，那么uni-app依然是首选。
- 开发轻应用：轻应用并没有流行起来。
- 多端并行开发：uni-app尽管花了很大的力气抹平了多端的差异，但是，抹平绝对不是那么简单的，复杂功能的话还是要分离开发，况且，业务上并不需要多端使用完全相同的界面、完全相同的功能，往往是分离开发，除非是业务需要同时开发微信小程序、百度小程序……各种小程序，它们的差异最小，这种情况是唯一值得并行开发的。
为什么不用小程序原生代码开发小程序？
- 需要花时间去学习。
- 只要是语言或者较为底层的框架，就一定要有生态，这个语言和底层框架才能良性发展，原生小程序的生态当然比不过Vue.js的生态，Vue的很多组件能直接用于uni-app开发小程序，更何况uni-app自身也有了一定规模的生态，很多开发者会开发一些.vue扩展名的组件用于小程序开发。
为什么不用weex开发APP？
- 需要去学习。
- weex官方不再支持Windows下开发，一旦出什么麻烦，没人解决，以后版本可能问题越来越多。
- uni-app已经在努力兼容weex。
如果打算只开发APP，怎么做？
只开发微信小程序的话，肯定是用微信开发者工具预览。但是，如果只开发APP呢？这时候你就有2种选择：
- 以开发小程序为标准开发APP，基于微信开发者工具，而不是基于H5，当然，手机模拟器肯定是要看的。也就是说，以微信开发者工具和手机模拟器这两个工具为预览。
- 以H5为标准开发APP，基于Chrome预览和手机模拟器预览。
这两种方案各自有优势，总体说：
- 你越打算贴近腾讯生态，越打算使用APP原生功能，或者知道某些功能在H5里不可能正常预览，你就越应该偏向微信开发者工具预览；缺点：开发速度略慢（微信开发者工具刷新速度慢），不能定制化原生组件。
- 你越希望定制化，越在意开发速度，你就越应该偏向H5预览。缺点：贴近腾讯生态的功能调试困难，APP原生功能预览困难，小程序组件无法定制。举个例子：如果你想调整
<swiper>的indicator-dots的位置，事实上通过H5可以改变indicator-dots位置，并且在APP上生效，但是小程序开发者工具预览的话，无论从API来看，还是到Wxml里找，都找不到修改indicator-dots位置的方法。
uni-app官方对于第三方组件库的说明
《关于uni-app的ui库、ui框架、ui组件》：https://ask.dcloud.net.cn/article/35489
开发小程序前提下，第三方组件兼容性测试
- 直接使用原生小程序组件，百分百可用。
- 使用针对vue的组件，这种直接拿来用的话，90%是可以用的。
- 使用不针对vue的组件，这种直接拿来用的话，无法使用的概率就大得多，可能只有80%或更少的组件能经过略微改造之后使用。
开发APP前提下，第三方组件兼容性测试
假设你基于小程序开发者工具预览，那么使用第三方组件的体验是跟上面是一样的：
- 直接使用原生小程序组件，百分百可用。
- 使用针对vue的组件，这种直接拿来用的话，90%是可以用的。
- 使用不针对vue的组件，这种直接拿来用的话，无法使用的概率就大得多，可能只有80%或更少的组件能经过略微改造之后使用。
现在假设你基于H5预览：
- 如果你用第三方原生小程序组件的话，uni-app会将原生小程序组件编译成H5可用代码，但是这里有个问题，就是原生小程序组件的开发者并不知道你是打算用在H5上的，所以有一定概率会编译出错。这里有个提醒，个别H5无法预览不代表APP里不可用，你还可以抱着一线希望看手机模拟器的预览。
- 如果你用针对vue的组件的话，看起来应该是万无一失的，不过复杂的组件也或许有小问题。
uni-app基于H5预览开发APP，引入Vant出错
首先说，用CLI方式创建项目，问题更多，我这边只用HBuilder X创建来说明。
- 引入vant的CSS报错
安装vant的方法是在项目目录执行yarn add vant，然后按照官方手册全局import。
此时H5预览项目你会发现CSS报错，解决办法是：
新建postcss.config.js，加入：
module.exports = {
exclude: ['node_modules/vant']
}
- 手机模拟器预览时出现：App平台 v3 模式暂不支持在 js 文件中引用"vant/lib/index.css" 请改在 style 内引用
那就在<style>里引用好了。
- 手机模拟器预览报
navigator.userAgent相关错误
Vant有使用navigator.userAgent，而APP中没有这个对象，所以肯定报错。
解决方案：这个问题比较麻烦，甚至会一票否决Vant。uni-app官方也说了，vant不是全端的组件库。所以我换成了使用Vant Weapp。
uni-app基于H5预览开发APP，引入Vant Weapp出错
引入方法见：https://uniapp.dcloud.io/frame?id=小程序组件支持
- 跟Vant一样的CSS报错。
三种预览方式对比一下：
H5表现：跟Vant一样，Vant Weapp也会CSS报错，也是postcss的报错。
小程序开发者工具里不会报错，因为我们用小程序组件，以开发者工具预览，既然是亲生的，当然没问题。
APP预览也会CSS报错，跟H5的报错内容一致。
我尝试模仿上文方案，加入这些代码来解决：
module.exports = {
exclude: ['wxcomponents/vant']
}
H5的表现：之前报错消失，出现两个新报错，
TypeError: Cannot read property 'split' of undefined和[Vue warn]: Failed to resolve async component，看起来极难解决。微信开发者工具的表现：一切正常。
手机模拟器的表现：能跑通，除了控制台报错
Method "$emit" conflicts with an existing Vue instance method，但不影响跑通。
结论：打算用Vant（或Vant Weapp）开发APP的话，似乎唯一的办法就是使用Vant Weapp，并且在小程序开发者工具里预览，以及手机模拟器里预览。
如果一定要用H5预览，且使用JS组件库，可以试试其他的组件库，uni-app官方给了一个表。uni-app官方认为Vant Weapp能在H5端正常使用，我上面说了，我难以做到，但你可以继续尝试。
uni-app在H5或小程序工具预览正常，编译为APP就一定正常么？
绝对不是！
这种编译本质还是将uni-app代码对应为APP需要的代码，这种对应是uni-app做的事，这就有趣了，这需要看uni-app提供商的水平了，事实上，尽管水平还可以，但是还是有很多问题，本身这种对应就比较机械，考虑的意外问题比较少，所以，你在H5或小程序工具一切OK的代码，编译成APP可能惨不忍睹。
所以我建议：
不要在APP中做复杂的布局，坑太多。
最好就是个图、文、表格、表单构成的简单APP，不要加入多媒体、地图之类复杂的东西，会让你有欲仙欲死的感受。
APP真复杂的话，请雇佣安卓和苹果工程师，如果公司太穷逼的话，干脆倒闭吧。
