这个搭配就是 c 站现在的搭配

前端，fre | flutter

后端，go

资料库，mysql | redis

C站

唔具体来说的话，我认为这个搭配非常适合小型团队

c站使用这个搭配稳定运行三年，我认为三年前我做这个选型的时候，是很有远见的

很多人问我，为什么是 go 而不是 node，说实话我三年前的 go 还没现在这么烂大街，当时 node 确实更火一点，但是我还是毅然选了 go

不为别的，我认为 go 真的比 node 更简单高效，特别适合写服务端，而且关键是，我不认为 ts 比 go 好，相反我觉得任何一个 jser 需要转 ts 的，都可以尝试一下 go

然后就是 flutter，c站的移动端经历了 hybrid，RN，flutter 的三次大版本的重构

我认为 flutter 对 c站来说确实是最优选，我们当时 RN 的主要痛点是打包调试体验极差，flutter 这方面做的很好，至少项目拉下来就能直接跑

资料库的话，其实我个人不是很喜欢 mysql 的，只是因为我不是这方面的专家，使用主流资料库会少很多坑，但是凭心而论我当时做选型的时候，是有考虑过 postgre 的

fre 没啥好说的，亲儿子

综上所述，这个搭配特别适合小公司和小团队

大公司的话其实架构错综复杂，我见过大公司基本都是 java 系，然后安卓ios都是原生，资料库都自研，比如阿里的 OceanBase

三年后的今天，我在重写 c 站的时候，还是觉得这个组合没什么毛病

如果题主没有加上 MySQL 的话，我觉得题主是来黑 Google 的 PL 水平的。

我觉得不会，不管是前端，后端还是资料库，都有非常多的选择。

我们要根据需要来选择技术，而不是遵循所谓的「标配」。如果几种技术都能满足需要，就看自己团队的情况，使用自己熟悉的技术。（我这里是从公司技术选型的角度出发来说的，如果是个人学习，我建议优先学习热门/主流/使用广泛的技术）

比如说在后端，就拿我最近看好的「golang」来说，也并非是所有项目都是最适合，在超高并发下，明显java和scala的表现更加稳健，在对延时极度敏感的情况下，rust更胜一筹。如果只考虑开发效率，python和node.js甚至是ruby，如果团队比较熟练的话，都可能比go更加的短平快。但对于新项目和新团队，我的确推荐go，比较平衡，也比较简单。评论区也有朋友说还有php，我个人一般不推荐逼格这么低的技术，而且合格的php程序员要价非常高，数量还十分稀缺，招一票只会埋雷的初级php程序员会是你公司的灾难。

资料库也是一样，mysql的scalability并不好，如果你想保持mysql的访问介面，你可以使用tidb，但是tidb的使用成本是相对昂贵的，在我们不需要事务和sql的时候，rocksdb可以提供非常廉价而且scalable的解决方案。如果我们需要存储海量的数据并且很依赖大数据处理，而且总是追加大量的小块数据，还可以使用hbase，hbase在有些情况下可能更便宜。当然，还有redis这样的内存nosql，方便你更便宜的支持更大的访问量。对于很多项目，我们可能同时使用多种持久化技术，我个人觉得没必要什么事都麻烦关系型资料库。

前端就更不用说了，一直都是军阀混战，你方唱罢我登场，从来就没有标配。flutter的优势并不明显，现在它不是王者，将来肯定还会有其他新的技术出现和它竞争，鹿死谁手，犹未可知。我甚至都怀疑是不是有可能真的在前端出现一个一统天下的技术，毕竟前端的需求更加多样化。

再夹带一点私货，多说一点未来的前后端开发需求。我个人觉得，以后的后端开发会更加多的考虑和大数据结合，和人工智慧演算法结合。前端开发虽然也还是会考虑兼容更多的客户端平台，电视，可穿戴等等，但不管什么设备，5G时代的增长很大程度会体现在视频上，得视频者得天下。

后端的需求维度很多，不太可能出现一劳永逸的技术。虽然随时可能出现PHP这类容易入门的技术凭借低廉的成本吃下大多数市场，但恐怕Golang没有同样低的门槛。

但是，看好Flutter在下一步取代目前的「前端工程化」方案（当然Flutter也总有一天会被某个「更优秀的Flutter」所取代）。因为前端除了给人看没有其他存在价值，评价的标准就简单多了：

只有技术偏执症患者才会这么认为吧。

推荐阅读：
相关文章