写uniapp 3年，如何评价它的优缺点？

在公司工作的缘故，我写uniapp已经有三年多了。
最初开始写uniapp，是因为外包交付的项目就是基于uniapp构建的。外包的代码质量本就不高，而且我之前一直专门从事react开发，不太喜欢vue2的语法，所以一开始我对uniapp特别反感，心里想着这是什么烂东西，为什么不用react - native？从接手外包交付的项目开始，再加上后来使用uniapp + vue3 + ts做了两个app，并且对这两个app都进行了长期的维护和迭代，到现在我对uniapp已经非常熟悉了。
下面我想根据自己的经验来评价一下uniapp，不过这里的前提是你确实有跨端开发的需求，希望能够实现一套代码多端打包这种情况。如果只是单纯开发某个平台的app或者web之类的，那我建议你还是不要选择uniapp了。
先来说说它的优点吧。
接着再讲讲它的缺点。
这里我们先不讨论性能方面的问题，不管是react和vue谁的性能更好，或者flutter、rn、uniapp哪个渲染更流畅之类的，这些都不是我选择技术栈的主要考量因素。首先，我自己没有对这些进行过验证，而且我自己的业务场景很少涉及canvas动画或者大量的dom操作，所以几乎没有渲染性能方面的要求。我一直认为，对于普通的web开发者来说，大多数性能问题主要是代码的设计或者实现存在问题，而不是框架本身的问题。有些开发者写代码时连基本的时间复杂度都不考虑，还疑惑为什么点击反馈慢。基本的时间换空间或者空间换空间的概念还是应该要有的嘛。退一步讲，数据量增大的时候能不能从需求层面进行优化？非要在前端处理几十万的数据，这合理吗？
话说得有点远了，本来还想写webview通信的，但是仔细想想，小程序里的webview本身通信机制就不太好。不像在ios或者android里的jsbridge那样，可以更好地进行通信。
最后总结一下，如果只是开发常规的app，不涉及太多canvas/dom操作之类的情况，我觉得uniapp基本上可以毫无阻碍地使用。但如果是相反的情况，那就要谨慎考虑了。我负责的一个app需要用到arcgis，说实话，遇到的问题特别多，到现在我还有个图层在web和android里能渲染，但是在ios里渲染不出来的问题没有解决，还好这个问题优先级不是很高，领导也就是偶尔想起来问问情况。echarts也经常出问题，比如之前发现Axis的formater函数无效。反正遇到这种问题大概率很难从原理上去解决，只能想一些变通的办法来处理。