前幾天在技術(shù)群里又看到有人在爭(zhēng)論C#和C++孰優(yōu)孰劣，說(shuō)實(shí)話這種爭(zhēng)論我見(jiàn)過(guò)太多次了。但今天我想聊個(gè)更有意思的話題：微軟明明有C++這個(gè)強(qiáng)大的工具，為什么還要費(fèi)勁巴拉地搞出個(gè)C#？

這個(gè)問(wèn)題困擾了我很久，直到我深入研究了微軟的技術(shù)發(fā)展歷程，才發(fā)現(xiàn)這背后有著非常精彩的商業(yè)和技術(shù)考量。今天就跟大家掰扯掰扯這個(gè)話題，相信看完你會(huì)對(duì)技術(shù)選型有全新的認(rèn)識(shí)。

?

?? 一切要從微軟和Sun的那場(chǎng)"恩怨"說(shuō)起

?? 微軟當(dāng)年差點(diǎn)成了Java的"帶頭大哥"

說(shuō)起來(lái)你可能不信，微軟當(dāng)年差點(diǎn)成了Java陣營(yíng)的核心玩家。那是90年代末，Java剛剛火起來(lái)，"一次編寫(xiě)，到處運(yùn)行"的口號(hào)喊得震天響。

微軟一看，這玩意兒不錯(cuò)啊！于是花錢(qián)從Sun那里買(mǎi)了Java授權(quán)，準(zhǔn)備大干一場(chǎng)。但問(wèn)題是，微軟這幫人就是閑不住，拿到Java后就開(kāi)始各種"優(yōu)化"：

• 專(zhuān)門(mén)針對(duì)Windows做了一堆性能調(diào)優(yōu)
• 加了一些Windows獨(dú)有的API調(diào)用
• 搞了些Java標(biāo)準(zhǔn)里沒(méi)有的擴(kuò)展功能

微軟的想法其實(shí)挺簡(jiǎn)單：既然大家都要用Java，那我就讓Java在Windows上跑得最好，這樣不就把用戶(hù)留住了嗎？記得當(dāng)所的VJ不？？？

?? 那場(chǎng)價(jià)值10億美元的教訓(xùn)

但是Sun公司不干了！他們覺(jué)著微軟這是在搞破壞，你這樣搞，Java的跨平臺(tái)特性不就沒(méi)了嗎？于是1997年，Sun直接把微軟告上了法庭。

結(jié)果大家都知道了：

• 微軟敗訴，賠了Sun整整10億美元
• Java授權(quán)被收回，相關(guān)產(chǎn)品必須停止開(kāi)發(fā)
• 微軟被迫另尋出路

說(shuō)實(shí)話，這10億美元花得挺冤的。但換個(gè)角度想，如果沒(méi)有這次敗訴，可能就沒(méi)有今天的C#了。有時(shí)候塞翁失馬，焉知非福。當(dāng)然Java也失去了最好用的IDE了，現(xiàn)在都是些什么玩意。

?? 為什么不直接用C++？這里面門(mén)道挺深

?? C++雖好，但真不是萬(wàn)能藥

很多人覺(jué)得，微軟既然有C++，干嘛還要重新造輪子？這就像問(wèn)一個(gè)木匠，你既然有鋸子，為什么還要買(mǎi)刨子？

看看下面這段C++代碼，你就明白了：

#include <iostream>
#include <string>
#include <vector>

class StringProcessor {
private:
    std::vector<std::string*> strings;

public:
    ~StringProcessor() {
        // 手動(dòng)清理內(nèi)存，一不小心就內(nèi)存泄漏
        for (auto* str : strings) {
            delete str;
        }
    }

    void addString(const std::string& str) {
        strings.push_back(newstd::string(str));
    }
};

再看看C#怎么寫(xiě)：

// C#寫(xiě)同樣的功能，簡(jiǎn)潔多了
public class StringProcessor {
    private List<string> strings = new List<string>();

    public void AddString(string str) {
        strings.Add(str);
    }
    // 不用擔(dān)心內(nèi)存泄漏，GC會(huì)幫你搞定
}

差別一目了然。C++雖然性能強(qiáng)悍，但寫(xiě)起來(lái)真的太累了，特別是做業(yè)務(wù)開(kāi)發(fā)的時(shí)候。

? 性能和效率，魚(yú)和熊掌能兼得嗎？

我以前帶團(tuán)隊(duì)的時(shí)候，經(jīng)常遇到這樣的場(chǎng)景：

用C++開(kāi)發(fā)：

• 一個(gè)簡(jiǎn)單的Web API，1個(gè)高級(jí)工程師寫(xiě)了2個(gè)月
• 各種內(nèi)存管理問(wèn)題，調(diào)試到懷疑人生
• 性能確實(shí)不錯(cuò)，但維護(hù)成本高得離譜

用C#開(kāi)發(fā)：

• 同樣的功能，1個(gè)中級(jí)工程師1周搞定
• 代碼清晰易懂，新人上手很快
• 性能雖然稍差一點(diǎn)，但對(duì)業(yè)務(wù)來(lái)說(shuō)完全夠用

這就是現(xiàn)實(shí)。在大部分業(yè)務(wù)場(chǎng)景下，開(kāi)發(fā)效率比執(zhí)行效率重要得多。多花幾毫秒的運(yùn)行時(shí)間，能省下幾個(gè)月的開(kāi)發(fā)時(shí)間，這筆賬怎么算都劃算。回想剛?cè)胄袝r(shí)寫(xiě)cgi的痛苦，有點(diǎn)想死的心了。。。

當(dāng)然現(xiàn)在有一個(gè)drogon C++的web框架也是非常牛了，不過(guò)生產(chǎn)中我還真沒(méi)聽(tīng)說(shuō)有誰(shuí)用過(guò)。

??? 微軟的聰明之處：不是替代，而是分工

?? 分層架構(gòu)才是王道

微軟其實(shí)很聰明，他們從來(lái)沒(méi)想過(guò)用C#完全替代C++，而是讓兩者各司其職：

業(yè)務(wù)應(yīng)用層 → C#        ← 快速開(kāi)發(fā)，易維護(hù)

框架平臺(tái)層 → C++       ← 高性能，穩(wěn)定性

系統(tǒng)內(nèi)核層 → C/C++     ← 底層控制

硬件驅(qū)動(dòng)層 → 匯編       ← 極致性能

這種設(shè)計(jì)真的很巧妙：

• 底層追求極致性能
  ：Windows內(nèi)核、.NET運(yùn)行時(shí)用C++
• 上層追求開(kāi)發(fā)效率
  ：業(yè)務(wù)應(yīng)用、Web服務(wù)用C#
• 各層職責(zé)明確
  ：沒(méi)有銀彈，但有最優(yōu)解

?? 看看微軟自己怎么選擇

有個(gè)很有意思的現(xiàn)象，微軟內(nèi)部的技術(shù)選擇其實(shí)很說(shuō)明問(wèn)題：

他們用C++的地方：

• Windows操作系統(tǒng)（沒(méi)得選，必須C++）
• .NET 底層（性能要求極高）
• DirectX游戲引擎（每一幀都很珍貴）
• Office核心引擎（處理大文檔必須快）

他們用C#的地方：

• Visual Studio的大部分UI功能
• Azure云服務(wù)的管理界面
• 各種企業(yè)級(jí)應(yīng)用
• 內(nèi)部工具和腳本

看到了嗎？連微軟自己都是這么分工的。

?? 時(shí)間證明了微軟的眼光

?? C#的跨平臺(tái)逆襲

最有意思的是，當(dāng)年Java起訴微軟的理由是"破壞跨平臺(tái)特性"，結(jié)果現(xiàn)在C#反而成了真正的跨平臺(tái)語(yǔ)言：

# 在Linux服務(wù)器上跑C#
dotnet run --urls http://localhost:5000

# 用Docker部署到任何地方
docker run -p 8080:80 myapp:latest

# 編譯成單一可執(zhí)行文件
dotnet publish -c Release --self-contained -r linux-x64

這種反轉(zhuǎn)真的很戲劇化。當(dāng)年Sun說(shuō)微軟破壞跨平臺(tái)，現(xiàn)在.NET Core/5+在跨平臺(tái)這條路上走得比Java還要激進(jìn)。

?? 現(xiàn)在的C#有多香？

作為一個(gè)寫(xiě)了十幾年代碼的老程序員，我必須說(shuō)現(xiàn)在的C#真的很香：

// 一個(gè)完整的Web API，代碼簡(jiǎn)潔得不可思議
[ApiController, Route("api/[controller]")]
publicclass OrdersController : ControllerBase {

    [HttpGet]
    public async Task<ActionResult<List<Order>>> GetOrders() =>
        Ok(await _db.Orders.Where(o => o.IsActive).ToListAsync());

    [HttpPost]
    public async Task<ActionResult<Order>> CreateOrder(CreateOrderRequest request) {
        var order = new Order { CustomerId = request.CustomerId };
        _db.Orders.Add(order);
        await _db.SaveChangesAsync();
        return CreatedAtAction(nameof(GetOrder), new { id = order.Id }, order);
    }
}

這種開(kāi)發(fā)效率，在C++時(shí)代是不敢想象的。

?? 給咱們C#程序員的幾點(diǎn)思考

?? 技術(shù)選型的幾個(gè)原則

基于微軟這個(gè)案例，我總結(jié)了幾個(gè)技術(shù)選型的經(jīng)驗(yàn)：

什么時(shí)候選C++：

• 做系統(tǒng)編程，比如寫(xiě)驅(qū)動(dòng)、操作系統(tǒng)
• 性能要求極高的場(chǎng)景，比如游戲引擎、高頻交易
• 需要精細(xì)控制硬件資源
• 已有大量C++代碼需要維護(hù)

什么時(shí)候選C#：

• 企業(yè)級(jí)應(yīng)用開(kāi)發(fā)（這是C#的主戰(zhàn)場(chǎng)）
• Web開(kāi)發(fā)和API服務(wù)
• 桌面應(yīng)用程序
• 需要快速原型開(kāi)發(fā)和迭代
• 團(tuán)隊(duì)技術(shù)棧以.NET為主

?? 幾個(gè)實(shí)用建議

不要有語(yǔ)言鄙視鏈心理

我見(jiàn)過(guò)太多程序員覺(jué)得C++比C#高級(jí)，C#比JavaScript高級(jí)。其實(shí)每種語(yǔ)言都有自己的適用場(chǎng)景，關(guān)鍵是選對(duì)工具解決對(duì)的問(wèn)題。

理解自己的邊界

作為C#開(kāi)發(fā)者，要知道什么時(shí)候需要調(diào)用native代碼。比如圖像處理、加密算法這些對(duì)性能要求極高的場(chǎng)景，該用C++就用C++，通過(guò)P/Invoke調(diào)用就行。

擁抱.NET生態(tài)

現(xiàn)在的.NET生態(tài)真的很豐富，從NuGet包管理到Azure云服務(wù)，從Entity Framework到SignalR，這些工具能大大提升我們的開(kāi)發(fā)效率。

??? 寫(xiě)在最后的三點(diǎn)感悟

寫(xiě)完這篇文章，我有幾點(diǎn)感悟想和大家分享：

1. ?? 務(wù)實(shí)勝過(guò)完美主義

微軟沒(méi)有追求一種語(yǔ)言統(tǒng)治所有場(chǎng)景，而是讓不同語(yǔ)言在最適合的地方發(fā)光發(fā)熱。這種務(wù)實(shí)的態(tài)度值得我們學(xué)習(xí)，技術(shù)選型不要完美主義，夠用就好。

2. ?? 開(kāi)發(fā)效率就是生產(chǎn)力

在這個(gè)快速迭代的時(shí)代，能快速實(shí)現(xiàn)功能比寫(xiě)出最優(yōu)化的代碼更重要。C#的價(jià)值就在于能讓我們把更多精力放在業(yè)務(wù)邏輯上，而不是和指針、內(nèi)存管理做斗爭(zhēng)。

3. ?? 生態(tài)比語(yǔ)言更重要

C#的成功不僅僅是語(yǔ)言本身，更重要的是整個(gè).NET生態(tài)。從開(kāi)發(fā)工具到部署平臺(tái)，從第三方庫(kù)到社區(qū)支持，這個(gè)完整的生態(tài)才是我們選擇C#的真正原因。

最后想問(wèn)問(wèn)大家：在你們的項(xiàng)目中，遇到過(guò)需要混用C#和C++的場(chǎng)景嗎？你們是怎么處理的？

還有，對(duì)于性能敏感的業(yè)務(wù)場(chǎng)景，你們有什么優(yōu)化經(jīng)驗(yàn)可以分享？

閱讀原文：原文鏈接