继续接上文，在用uniapp框架的时候遇到各种疑难杂症，其实uniapp这个东西 本质是好的，最开始在定框架的时候，也就是从demo看起，觉着没什么问题了。就用了，随着业务逻辑的复杂程度程指数上升，发现uniapp各种弊端出来了，但优缺点是并存的。开发效率是毋庸置疑的，开发成本也是最低的。
去年上半年，遇到了个问题，如何激活用户，那第一个想到的就是通知了，通知的问题怎么说呢，用了个三方sass，可能重来没搞过这种混编语言，又叠加三方SASS 给的DEMO有问题，就一直没调通，甚至一度怀疑三方有BUG，找了N 个技术群 及客服。连燃这么优秀的程序都没有搞定。因为我非常相信燃的水平，他搞不定的。那肯定是有BUG，就这样APP 一直没通知的运行着。
上天总是在困难时刻眷顾我们，团队去年在积极扩招的同时，遇见了有开发uniapp经验的同学恰好搞过推送这一套，就这样入职，顺利调通推送。
（事实证明）有时候不是你能力不够，而是有可能你陷入了一个误区出不来了，换个思路或者换个人来看可能会更好。\
运营通知本就属于一个系统 从APP 到微信 甚至短信 要保证一套成熟的系统运营就要有以下特点
1、确保消息不丢失
2、消息推送足够快
创业公司跟大公司比，即没有成熟的技术中台，也没有成熟的技术组件，一切只能靠自己搭建，最开始的方案很简单，就是php单应用与redis队列 这种推上千没问题 一旦推几十万 的消息。很慢 很卡。
我们虽没有大公司那么多资源，但原理还是懂一些的，从redis list 到一致性的rabbitmq 从php单应用推送 到 go的协程并发推送。
就解决了以上俩个问题
1、消息不丢失了
2、推送足够快了
之前看评论有人说PHP，python 运行慢，嗯。能说出这话人算内行了，php开发快，运行慢。确实是一个弊端，但最开始它是试错最好的语言之一，没有业务关联的技术，就是纸上谈兵，空谈技术，没有任何意义。先生存，在升级。目前我们正计划拥抱另一个GO语言。采用php+go的模式让慢的地方快一点，当然了快速迭代的业务依然采用目前架构。
