這個搭配就是 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」所取代）。因為前端除了給人看沒有其他存在價值，評價的標準就簡單多了：

只有技術偏執症患者才會這麼認為吧。

推薦閱讀：
相关文章