markgor

@bestie 为什么走不通？获取用户基本信息(UnionID 机制)就是通过提供 openID 换取 unionID 的啊

1 、先去开放平台 注册+认证+绑定对应的小程序和公众号；
2 、小程序的直接获取 unionId 即可。公众号的通过获取用户基本信息接口，传递 openId 过去，换取 unionId 回来。
3 、此时 unionId 均一致了，用户侧做个账户选择就好了

@bug51 weex 是阿里开源的一个技术吧，然后 uniapp 跟进，就上面有人说到的 nvue ，但是吧，之后阿里好像是没继续维护 weex 了，然后就变成 uniapp 这边接手维护 nvue 。说真的我目前上线了 2 个 APP ，均没使用 nvue ，限制比较多，而且我也还没到达性能瓶颈，你看看现在换手机架构的迭代频率......大部分情况下性能没太大问题。
不过现在 uniapp 好像也停止维护 nvue 了，改成了主要维护推进 uts ，编译成原生语言，但这个我没接触过。


而 uniapp 其实没那么万金油，针对不同平台小程序和不同平台(IOS/ANDROID/H5/MP-*)都有特定的条件编译方法。
当跨平台的时候，你可以理解为：80%的代码是复用的，剩下 20%可能需要针对特定环境做差异化条件编辑。
我没接触过 flutter 和 react 这些没法比较，但是就目前而言，uniapp 的缺点在我接受的范围内，所以我选择 uniapp 。


我觉得更多时候，项目还没上线，就按着几万日活的方向去考虑选型，完全是没必要。
打造 100 款 APP ，都未必能有一个到达几万日活量，何必在这里浪费时间呢。
倒不如一把梭，用 uniapp 快速上线验证业务，然后真的到达了过万的日活量，再去考虑替换。

@markgor 就類似 v2 看到的帖子，大量 dom 元素 h5 下的性能調優。
通過 UNIAPP 去開發，和 H5 一樣甚至性能不如 H5 ，但是市場有很多插件，如虛擬滾動之類的來降低性能的影響。
如果你想用安卓和 ios 原生的解決方式降低損耗，你可以變異為 weex 模式，這個模式下有專用的組件可以讓變異出來的和原生性能上基本一致。但是很麻煩很麻煩。
而 utx 模式下官方我看建議是用類似 canvas 的方式去繪製過多的 dom 元素來提升性能。

你可以看看 GOV 部分的 APP ，都是 UNIAPP 打包的。
另外“实践多吗”----多
“是否适合使用”---看場景，如果你是大廠那些 APP ，擁有龐大的用戶，那不適合，如果你沒去到大廠那些用戶體量，那就適合。
uniapp 非 uts 和 weex 模式下，界面和功能基本能覆蓋 90%，剩下 10%可以通過自己封裝 sdk 給 uniapp 調用；
weex 模式就是功能上基本一致，但是 CSS 用法和 JS 部分有一點差異，但是主打性能。
而 uts 新出的模式，看了下文檔好像就是類似 flutter 那樣。
hbuilder 則不做評論，我用的時候經常莫名閃退，或者提示異常。但是都在我忍受範圍內。

那不是更好吗？我没理解错就是集团控制产品，但是门店私下找业务开账号管理。
但是到了对账时候，查北极星开放平台，反回了该商户 集团控制的单号 和 线下私开 的单号。
那只需要匹配上集团控制的单号，剩下私开的不就一下一目了然了吗？
如果没有返回 线下私开 的订单，那不就永远不知道店铺有私开账号的情况吗？

@zhousir5071 如果你一出生，
你父母和你說地球不是圓的，
然後你居住的地方人們都是地平論者，
很快你也會成為地平論者。
如果你一開始就知道這隻是個謊言，你會嘗試走出平時生活的這片區域，找到更多志同道合的和你一起說地球不是平的。
但是如果你並不知道的情況下，又會因為什麼驅使你走出平時生活的這片區域呢？

就如你所說的，“做正确的事情......这样的话，生活很快好转”，可是當周邊都是做著你認為的錯誤實情時候，主角根本不會意識到自己在做“錯誤”的實情，他也只是在做他認為“正確”的實情

@zhousir5071 所謂的對錯都是根據自己樹立的世界觀去判斷別人的對錯。
而孩子出生來到這個世上，更多的是遵從了父母的世界觀，當然不排除也有通過和外界接觸，理解到的世界觀。

在亲都好，始终是别人家事，看不过眼可以和你大姨说说，但怎么选择是你大姨的权利，而且她自始至终都是用自己的钱。