@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 就很合适。
如果本身就是做个业务后台，查查数据库，那么没什么必要换，费劲不讨好

https://youke.nali.net/geek.php?w=%3C\script%3E%3Cscript%3Ealert(1)%3C/script%3E

广东电信，最新情况，用不了了。。

@MontagePa 套壳的话哪还讲究是否对应。。。用 RN 自己封 shell 是为了避免第三方打包不好对接的坑。同时上架也好做，可以自己加一些原生页面来应付审核，主业务还是用 web 就好。
总之还是最好有计划投入点成本在其中。直接用那些垃圾玩意很容易失控。。。说那么多是因为我有过跟你类似的想法，也尝试过很多种方案，最终还是老实自研，哎

有预算的话，可以加 V ywisax 探讨啊

这个价位买不到靠谱的。如果仅仅是 server 端实现的话就好搞。要加上 app 的话不好做。
这个价位最可能实现的方案是 人人 /禾匠 等各种盗版商城+套壳。但是实际体验真的很差。。。例如套壳之后路由跳转的交互、原生能力的桥接（如微信登录、分享）等都需要大量时间去做各种 fix，实际开发成本很容易失控。别太迷信各种 H5 打包的在线服务，没几个真能用的，特别点名 YDB 就是个大坑。
我建议是：如果只是为了快速上线应付交付的话，套壳就是了；如果是为了自有项目找方案，那么降低要求，买个可靠的 server 端，自己用 RN 来封个 shell 来做 app。

你的 view，应该类似这样才行

```
<?php
$this->beginPage();
$this->head();
$this->beginBody();
$this->endBody();
$this->endPage();

```

@wafm 微信跟 v2 的 ID 一样

搭车，微信 ywisax