支持一下

IM 客户端出一个 RN 版本的吧

不是很稳定的做法咯

果断 bigo 咯

记得纸面确认你所应得的

讲真没什么吸引力。。。

DevDocs

@raynor2011 我描述和计算的数据有误，应该有 200 多 qps。流量不会均摊到 24 小时，所以我这里计算 qps 都是按照 7 或 8 小时来计算

如果百万是指 PV 的话，一小时百万其实要求不高了吧。
按照 7 小时计算，也就几十 qps，做不到就太菜了。
预算就真的要认真斟酌下。考虑外地公司的可以聊聊。

同 1L。where 都走了索引的话，查询起来应该不会很慢，就是插入比较蛋疼

我个人觉得你这 CTO 还是挺好的，例如 尽可能把锅都丢给服务端，这点意思应该是业务尽可能给服务端去做，客户端只做渲染。

@hujianxin 简直生无可恋了。烦死这玩意了还是得抢着用

@haoji 这不是比烂大赛啊。。。微信这边搞了那么久了，开发者工具居然还是这个鬼样，真让人难以理解

@lhx2008 稍微大点的项目都会卡。你整一些重度一点的产品，上一些他们吹的高级一点的特性（分包、插件等等），你就会同样要发狂了

目标是快速开发的话，那么选型的优先级应该是 网页套壳 > DCloud、APICloud > React Native、Weex > Flutter
吹 flutter 也无所谓，不过要好好审题先吧。

我比较粗暴，直接 vendor 也加入版本控制。。

如果是做 CURD，那么还是 PHP 吧。语言的确不是很大问题。
一般比较正确的做法是遇到瓶颈了使用其他语言方案来补充。例如 php 的异步 IO 就做得不好（ swoole 是一个方案但毕竟还是不够成熟），那么这部分业务换 node、java 就很合适。
如果本身就是做个业务后台，查查数据库，那么没什么必要换，费劲不讨好