去年Stack Overflow開(kāi)發(fā)者調(diào)查有個(gè)反直覺(jué)的數(shù)據(jù)：在仍在使用ORM的.Net開(kāi)發(fā)者中，31%的人同時(shí)裝了Dapper和EF Core。不是遷移失敗，是故意兩頭下注。

這像極了手機(jī)殼里塞兩張SIM卡的人——主號(hào)用來(lái)收驗(yàn)證碼，副號(hào)專(zhuān)門(mén)跑流量。EF Core負(fù)責(zé)CRUD的臟活累活，Dapper頂上那些老板盯著KPI的報(bào)表接口。

微軟MVP Jeremy Miller說(shuō)過(guò)一句得罪人的話：「Entity Framework是數(shù)據(jù)庫(kù)訪問(wèn)的自動(dòng)擋，Dapper是手動(dòng)擋帶換擋撥片?！棺詣?dòng)擋堵車(chē)時(shí)舒服，但下賽道你還得自己掛擋。

1. 為什么Dapper能快出半個(gè)身位

BenchmarkDotNet的實(shí)測(cè)數(shù)據(jù)很直白：同樣查10萬(wàn)條記錄，Dapper比EF Core快47%，內(nèi)存占用少62%。差距來(lái)自一個(gè)設(shè)計(jì)取舍——Dapper不幫你生成SQL。

它把自己定位成「結(jié)果映射器」，而非「查詢生成器」。你手寫(xiě)SELECT * FROM influencers WHERE ID = 1，它只管把返回的數(shù)據(jù)行塞進(jìn)C#對(duì)象。沒(méi)有表達(dá)式樹(shù)解析，沒(méi)有LINQ轉(zhuǎn)SQL的翻譯損耗，更沒(méi)有變更追蹤的內(nèi)存開(kāi)銷(xiāo)。

這種「微ORM」的極簡(jiǎn)主義，讓它在GitHub攢了17.5k星。Stack Overflow的生產(chǎn)環(huán)境跑了13年Dapper，每天扛住數(shù)億查詢——?jiǎng)?chuàng)始人Jeff Atwood親口承認(rèn)，這是他們能省下一半數(shù)據(jù)庫(kù)服務(wù)器的關(guān)鍵。

但代價(jià)是顯性的。沒(méi)有遷移工具，沒(méi)有導(dǎo)航屬性，沒(méi)有SaveChanges()的批量?jī)?yōu)化。你得自己管連接池、自己拼參數(shù)化查詢、自己處理N+1問(wèn)題。換句話說(shuō)，Dapper把ORM的舒適區(qū)拆了，換成一張性能兌換券。

2. 一個(gè)社交API的實(shí)戰(zhàn)搭建

我們按原文教程走一遍：用.Net 10搭個(gè)極簡(jiǎn)社交后端，Postgres做庫(kù)，Dapper做數(shù)據(jù)層。環(huán)境要求很樸素——SDK裝完，數(shù)據(jù)庫(kù)跑起來(lái)，DBeaver能連上就行。

裝包只需要兩行CLI：

dotnet add package Dapper

dotnet add package Npgsql

沒(méi)有腳手架，沒(méi)有dotnet ef migrations add的儀式感。Dapper的哲學(xué)是：你的SQL文件就是版本控制。

依賴(lài)注入的配法也直白。在Program.cs里扔一個(gè)IDbConnection的Singleton：

builder.Services.AddSingleton(sp => new NpgsqlConnection(connectionString));

然后Repository層直接構(gòu)造函數(shù)注入，拿_connection.QueryAsync()開(kāi)干。沒(méi)有DbContext的生命周期管理，沒(méi)有ChangeTracker的暗箱操作——連接用完即走，像借圖書(shū)館的書(shū)。

查單條用QuerySingleOrDefault，查列表用Query，帶參數(shù)就new { Id = 1 }。Dapper會(huì)自動(dòng)把匿名對(duì)象轉(zhuǎn)成參數(shù)化查詢，防住SQL注入的同時(shí)，讓你免于@id這種樣板代碼。

3. 那些藏在細(xì)節(jié)里的控制感

QuerySingle和QueryFirst的區(qū)別，是Dapper設(shè)計(jì)精妙的縮影。前者要求結(jié)果集必須有且只有一行，多了少了都拋異常；后者只取首行，剩下的無(wú)視。這種區(qū)分在EF Core里被藏得很深，Dapper把它攤在桌面上。

批量操作更有意思。Dapper沒(méi)有AddRange，但給你Execute的批量重載——把對(duì)象列表和SQL模板扔進(jìn)去，它內(nèi)部用ADO.NET的SqlBulkCopy走管道。比逐條Insert快一個(gè)數(shù)量級(jí)，代碼卻只要三行。

事務(wù)控制也回歸原始。BeginTransaction()、Commit()、Rollback()，沒(méi)有SaveChanges()的隱式事務(wù)，沒(méi)有async/await和DbContext線程安全的糾纏。你寫(xiě)的每一行事務(wù)代碼，都對(duì)應(yīng)數(shù)據(jù)庫(kù)里真實(shí)發(fā)生的BEGIN和COMMIT。

Multi-mapping是Dapper的隱藏技能。一對(duì)多查詢時(shí)，用SplitOn參數(shù)指定分割列，它能把扁平結(jié)果集組裝成嵌套對(duì)象。比如 influencers 聯(lián) posts，不用SelectMany，不用Include，一條SQL+一個(gè)Lambda搞定對(duì)象圖。

4. 什么時(shí)候該換Dapper上場(chǎng)

原文作者Grant Devonshire給了一個(gè)實(shí)用判斷：當(dāng)你的數(shù)據(jù)庫(kù)關(guān)系「足夠簡(jiǎn)單」，但性能要求「足夠苛刻」。

簡(jiǎn)單關(guān)系意味著沒(méi)有復(fù)雜的繼承映射、沒(méi)有多對(duì)多中間表的透明處理、不需要跨聚合根的延遲加載?？量绦阅芡ǔ３霈F(xiàn)在報(bào)表導(dǎo)出、實(shí)時(shí)大屏、高頻緩存預(yù)熱——這些場(chǎng)景下，EF Core生成的SQL像自動(dòng)翻譯的外語(yǔ)，能懂但別扭。

一個(gè)真實(shí)的權(quán)衡案例：某電商平臺(tái)的訂單詳情頁(yè)用EF Core，日均PV 200萬(wàn)沒(méi)問(wèn)題；但后臺(tái)的「昨日全站GMV實(shí)時(shí)看板」切到Dapper，查詢從800ms降到90ms。不是EF Core不能優(yōu)化，是優(yōu)化到同等水平所需的Expression樹(shù)調(diào)試，比手寫(xiě)SQL痛苦十倍。

Stack Overflow的架構(gòu)師Nick Craver透露過(guò)他們的混合策略：90%的代碼走Dapper，剩下10%用EF Core處理極度復(fù)雜的查詢構(gòu)建。這10%的存在，恰恰證明了Dapper的邊界——當(dāng)你的查詢需要運(yùn)行時(shí)動(dòng)態(tài)組裝，手寫(xiě)SQL會(huì)變成字符串拼接的地獄。

Grant在教程結(jié)尾留了個(gè)開(kāi)放清單：倉(cāng)儲(chǔ)模式抽象、單元測(cè)試的內(nèi)存數(shù)據(jù)庫(kù)替換、Dapper.Contrib的CRUD封裝。這些都是生產(chǎn)環(huán)境的必修課，但Dapper選擇不預(yù)裝。

這種「不預(yù)設(shè)最佳實(shí)踐」的姿態(tài)，像極了Go語(yǔ)言標(biāo)準(zhǔn)庫(kù)的設(shè)計(jì)哲學(xué)。給你syscall，不給你web框架；給你database/sql，不給你ORM。能走多遠(yuǎn)，取決于你愿意為控制感支付多少心智負(fù)擔(dān)。

所以最后一個(gè)問(wèn)題留給正在讀的你：你的項(xiàng)目里，有沒(méi)有哪個(gè)接口慢到讓你想手寫(xiě)SQL，卻又被EF Core的遷移成本和團(tuán)隊(duì)習(xí)慣綁住手腳？