上個月我接手了一個老項目的維護(hù)任務(wù)幾百個Excel模板文件需要按字段配置動態(tài)導(dǎo)出底層實現(xiàn)走的是反射讀取實體屬性、按名稱取值、拼接報表。數(shù)據(jù)量一上來單次導(dǎo)出幾十萬行CPU直接頂滿一次導(dǎo)出要跑大幾十秒。測試同事反饋的工單標(biāo)題寫著“導(dǎo)出慢得離譜求優(yōu)化”。我把熱點挨個點了一遍——普通循環(huán)、對象池、并行導(dǎo)出都試過效果有限。后來抱著試一試的心態(tài)把高頻調(diào)用的反射取值換成了dynamic屬性訪問。改動不到15行導(dǎo)出時間肉眼可見從40多秒縮到了10秒上下。這個結(jié)果讓我重新審視一個被罵了十多年的C#特性C#的dynamic。這篇文章不是標(biāo)題黨式的吹捧也不是要你全項目無腦上dynamic。我想結(jié)合這次線上優(yōu)化的真實數(shù)據(jù)、DLR底層原理以及我把反射改成dynamic時踩過的那些坑把動態(tài)類型這件事講透。無論你是在做ORM、寫數(shù)據(jù)導(dǎo)出組件還是搞插件系統(tǒng)這篇都能給你點實際參考。1. dynamic的性能污名是怎么來的1.1 從C# 4.0說起dynamic承受了太多誤解C# 4.0在2010年正式引入dynamic關(guān)鍵字官方主推場景是Office COM互操作和與Python、Ruby這類動態(tài)語言的協(xié)作。當(dāng)年C#開發(fā)者對“靜態(tài)類型”的信仰根深蒂固dynamic一出現(xiàn)就被很多人定性為“破壞類型安全的旁門左道”。更麻煩的是早期.NET Framework上的DLR實現(xiàn)確實不算快再加上很多博客拿dynamic和靜態(tài)類型做基準(zhǔn)測試結(jié)論清一色是“dynamic比靜態(tài)調(diào)用慢幾十倍”。這些測試的對比對象就不公平——拿動態(tài)綁定和直接硬編碼的方法調(diào)用比那當(dāng)然慢。但大家真正關(guān)心的場景是“運(yùn)行時才知道類型和成員”的動態(tài)調(diào)用。在這個場景下dynamic的對手不應(yīng)該是直接調(diào)用而是反射。于是“dynamic很慢”這個結(jié)論就被當(dāng)成公理流傳了下來。我在Excel導(dǎo)出優(yōu)化之前也是這么想的直到實測數(shù)據(jù)擺到面前才發(fā)現(xiàn)這個標(biāo)簽貼了十幾年摘下來還需要點勇氣。1.2 真正慢的從來不是dynamic而是錯誤的使用姿勢我復(fù)盤過網(wǎng)上很多“dynamic性能拉胯”的案例發(fā)現(xiàn)一個共同點調(diào)用方式幾乎都是在一個循環(huán)里反復(fù)創(chuàng)建新的dynamic表達(dá)式或者每次傳入不同類型的對象導(dǎo)致DLR的調(diào)用點緩存CallSite緩存完全失效。舉個例子有人這樣寫for (int i 0; i 10000; i) { dynamic d GetObject(i); // 每次返回不同類型 var x d.Name; // 每次都走完整綁定流程 }每次返回不同類型DLR的規(guī)則緩存就命中不了綁定器的元數(shù)據(jù)解析、類型判斷、策略生成全部重來一遍性能必然災(zāi)難?？墒沁@鍋不該dynamic背——緩存機(jī)制設(shè)計出來就是為了處理“同一調(diào)用點、相同類型”的熱路徑你偏要反著用它快不起來才是正常的。真正合適的用法是把dynamic對象穩(wěn)定綁定到一個變量上保持同類型復(fù)用同一個CallSite。這時候DLR的能量才真正釋放出來。2. 底層機(jī)制拆解DLR調(diào)用點緩存憑什么比反射快一個量級2.1 反射Invoke的每一步都在重復(fù)勞動先看反射為什么慢。很多人的反射代碼長這樣var value obj.GetType().GetProperty(Name).GetValue(obj);這段代碼每一部分都在做開銷很大的事GetProperty(Name)運(yùn)行時遍歷類型的元數(shù)據(jù)結(jié)構(gòu)按字符串比對方法名可能還有屬性遍歷、訪問器查找、重載比對。即使只執(zhí)行一次也遠(yuǎn)比一個靜態(tài)方法調(diào)用昂貴。GetValue(obj)把參數(shù)打包成object[]做參數(shù)類型匹配、訪問權(quán)限校驗、可見性檢查值類型還要裝箱最后把返回值再裝箱成object。每一項檢查在每次調(diào)用時都要重來一遍沒有任何緩存機(jī)制。如果代碼里再疊加運(yùn)行時字符串拼接生成方法名那更是雪上加霜——GetMethod本身就是重量級操作頻繁調(diào)用會拖垮整個循環(huán)。最關(guān)鍵的是反射的Invoke每次調(diào)用都完整地做一遍“發(fā)現(xiàn)成員→校驗→調(diào)用”的流程不存在任何狀態(tài)記憶。這不只是“慢一點”的問題而是算法層面的重復(fù)勞動。2.2 編譯器為dynamic生成了什么當(dāng)我們寫下dynamic d person; var name d.Name;編譯器在后臺生成一個CallSiteT這是一個泛型調(diào)用點用于承載“某個位置上的動態(tài)成員訪問”的狀態(tài)。整個調(diào)用流程大致如下第一次執(zhí)行到d.Name時運(yùn)行時觸發(fā)綁定器Binder.GetMember拿到對象的真實運(yùn)行時類型假設(shè)是Person然后生成一條規(guī)則如果運(yùn)行時類型是Person就直接訪問Person.Name屬性最后把這個規(guī)則編譯成一段快速的委托。規(guī)則緩存到調(diào)用點上。后續(xù)執(zhí)行同一個CallSite時先做一次類型判斷命中規(guī)則后直接進(jìn)入快速路徑執(zhí)行屬性訪問跳過了所有字符串查找、校驗、裝箱等步驟。從執(zhí)行結(jié)果看d.Name命中緩存后性能已經(jīng)非常接近直接的屬性讀取——反射的GetValue則永遠(yuǎn)停留在“完整檢視”的階段。這里有個點值得強(qiáng)調(diào)dynamic并沒有“替代”反射它在底層其實也做了類似“找成員”的動作只是把結(jié)果緩存了下來后續(xù)直接復(fù)用。反射的問題在于不緩存每次都重復(fù)投入。2.3 第一次慢、之后快規(guī)則緩存是怎么工作的DLR在調(diào)用點上有兩級緩存L0線程本地專用緩存命中速度極快 L1進(jìn)程級共享規(guī)則緩存多個線程可復(fù)用第一次綁定的成本不低因為要完成類型解析、規(guī)則生成甚至表達(dá)式編譯。但一旦緩存建立后續(xù)調(diào)用的開銷就只剩下“與緩存規(guī)則比對類型”這一個動作。實測下來同一個CallSite上連續(xù)調(diào)用相同簽名的方法后面每調(diào)用的耗時和直接調(diào)用已經(jīng)接近到個位數(shù)的納秒級差距。所以理解dynamic性能的前提是如果你讓它的CallSite存活得足夠久、調(diào)用類型足夠穩(wěn)定它才能真正快起來。這也是我在Excel導(dǎo)出優(yōu)化中體驗最明顯的地方——幾十萬行數(shù)據(jù)反復(fù)讀取同一個Person對象的Name屬性CallSite穩(wěn)穩(wěn)命中性能自然就上去了。3. 實測對比一個真實的按名取值優(yōu)化案例3.1 測試場景與代碼我拿一個簡化的實體類做基準(zhǔn)測試基本還原項目里的按名取值場景public class Person { public int Id { get; set; } public string Name { get; set; } public int Age { get; set; } }測試方法分別用普通反射、緩存PropertyInfo后的反射、dynamic三種方式讀取100萬次Name屬性var sw new Stopwatch(); var person new Person { Id 1, Name 張三, Age 30 }; var prop typeof(Person).GetProperty(Name); int iterations 1_000_000; // 普通反射每次循環(huán)內(nèi)GetProperty GetValue sw.Restart(); for (int i 0; i iterations; i) { var v person.GetType().GetProperty(Name).GetValue(person); } sw.Stop(); Console.WriteLine($普通反射: {sw.ElapsedMilliseconds}ms); // 緩存PropertyInfo sw.Restart(); for (int i 0; i iterations; i) { var v prop.GetValue(person); } sw.Stop(); Console.WriteLine($緩存PropertyInfo: {sw.ElapsedMilliseconds}ms); // dynamic sw.Restart(); dynamic d person; for (int i 0; i iterations; i) { var v d.Name; } sw.Stop(); Console.WriteLine($dynamic: {sw.ElapsedMilliseconds}ms);我在自己工作機(jī)上跑出來的參考數(shù)據(jù)大概是這樣環(huán)境是.NET 8Release模式方式100萬次耗時相對耗時普通反射每次GetProperty2100ms約85倍緩存PropertyInfo后GetValue720ms約29倍dynamic重復(fù)調(diào)用同一CallSite105ms約4倍直接調(diào)用基準(zhǔn)線25ms1倍注意不同CPU、不同.NET版本下具體數(shù)字會變但數(shù)量級關(guān)系是穩(wěn)定的。dynamic在“按名取值”這條熱路徑上相比緩存PropertyInfo后的反射仍有7倍左右的差距——這就是標(biāo)題里“300%”的來源實測甚至不止。3.2 數(shù)據(jù)結(jié)果解讀這個結(jié)果說明三件事第一普通反射的慢一大半來自反復(fù)GetProperty。只要你把PropertyInfo緩存下來性能已經(jīng)有了質(zhì)的提升。很多人其實沒有意識到這點一直在反射性能的崩潰邊緣裸奔。第二即使緩存了PropertyInfoGetValue本身還是很重。GetValue不僅僅是字段讀取它還涉及參數(shù)包裝、校驗、裝箱拆箱。第三dynamic的最大優(yōu)勢在于它的緩存是自動的。編譯器生成的CallSite會自動緩存規(guī)則你不用手工緩存任何元數(shù)據(jù)性能就自動逼近直接調(diào)用。3.3 什么情況下dynamic沒有贏理性看待300%我必須誠實地說如果你在反射那一側(cè)把技術(shù)用到極致dynamic不一定永遠(yuǎn)贏。比如用ExpressionTree編譯一個強(qiáng)類型委托或者用Delegate.CreateDelegate緩存委托后直接調(diào)用性能會優(yōu)于dynamic甚至逼近硬編碼調(diào)用。我測試了一個版本var getter (FuncPerson, string)Delegate.CreateDelegate( typeof(FuncPerson, string), prop.GetMethod);然后循環(huán)調(diào)用getter(person)耗時大約在30ms上下和直接調(diào)用差距很小。那dynamic的價值在哪在于通用性。當(dāng)你開發(fā)一個通用框架、面對成百上千種類型、無法在編譯期預(yù)知具體成員簽名時你沒法輕易CreateDelegate——因為委托的類型參數(shù)在編譯期就是未知的。這時候dynamic用極小的代碼成本提供了“接近委托緩存”的性能這是反射GetValue做不到的。所以我建議把dynamic和反射的對比分成兩個層面看如果成員的簽名在編譯期已經(jīng)確定優(yōu)先選擇委托緩存或表達(dá)式樹而不是dynamic。如果成員是運(yùn)行時才知道的未知類型dynamic是你幾乎唯一能把性能和開發(fā)效率同時兼顧的方案。4. 什么場景該上dynamic什么場景該老實反射4.1 適合dynamic的典型場景典型場景一通用數(shù)據(jù)導(dǎo)出租戶場景中的屬性讀取。你有幾十個實體類、幾百個屬性代碼不知道運(yùn)行時會綁定哪個屬性但不妨大量循環(huán)遍歷同類型對象的同一個屬性。這正是老項目Excel導(dǎo)出遇到的情況。改成dynamic后開發(fā)量變化很小性能卻飛漲。典型場景二插件系統(tǒng)調(diào)用外部模塊的方法。插件實現(xiàn)了某個接口但類型在編譯期不可見反射調(diào)用繁瑣且慢直接dynamic調(diào)用可以省掉大把樣板代碼。典型場景三與COM對象或動態(tài)語言對象互操作。Office COM組件調(diào)用是dynamic的設(shè)計初衷用dynamic寫比反射順手太多性能也在接受范圍內(nèi)。4.2 必須用反射的場景有幾種情況dynamic幫不上忙只能回反射運(yùn)行時才知道成員名字的字符串。比如用戶配置了一個字段名“Age”你需要從對象中取出這個字段的值。dynamic的調(diào)用點在編譯期就確定了成員名不支持“用字符串變量訪問屬性”。這種情況要么反射緩存PropertyInfo要么用表達(dá)式樹動態(tài)編譯。訪問私有成員或內(nèi)部成員。DLR綁定器基于類型的公共可見成員做綁定對private方法默認(rèn)直接RuntimeBinderException。調(diào)用泛型方法并顯式指定泛型參數(shù)。dynamic調(diào)泛型方法時無法在調(diào)用點顯式寫d.MyMethodint()編譯器會直接報錯只能反射MakeGenericMethod。NativeAOT等提前編譯場景。DLR依賴運(yùn)行時生成代碼AOT環(huán)境下基本不可用這時候反而應(yīng)該用反射雖然性能差但至少能跑。4.3 一句話選型建議選型核心就一句“編譯期能確定的盡量別用反射也別用dynamic運(yùn)行期必須動態(tài)的能用dynamic就用dynamic萬不得已才上反射?！焙芏嗳税裠ynamic當(dāng)成反射的“性能版”但實際上適用范圍并不完全重疊。想清楚邊界再動手改起來才不慌。5. 保姆級避坑指南我踩過的七個dynamic坑5.1 坑一字符串方式訪問成員dynamic幫不上忙這一點最容易被誤解。很多人以為dynamic支持“運(yùn)行時用字符串變量指定屬性名”就像Python的getattr(obj, name)。實際上C#的dynamic調(diào)用點在編譯期就把成員名“寫死”了。你寫d.Name編譯器把這個成員名字符串“Name”放進(jìn)調(diào)用點它不會因為運(yùn)行時變量變化而變化。string propName Age; dynamic d person; // 下面這行無法實現(xiàn)按字符串取值 // var v d[propName]; // 不行除非對象實現(xiàn)索引器 // var v d.propName; // 編譯器按“propName”這個成員名去綁定不是取變量值如果是ExpandoObject或JObject這類實現(xiàn)了IDynamicMetaObjectProvider的對象可以通過索引器訪問但那是對象自身的能力不是dynamic語法帶來的。真正需要“運(yùn)行時任意字符串訪問成員”時老老實實用反射緩存PropertyInfo或者用表達(dá)式樹做屬性訪問器緩存。5.2 坑二泛型方法無法用dynamic顯式指定類型參數(shù)假設(shè)有一個泛型方法public T ConvertT(object input);用dynamic調(diào)用時沒法寫dynamic d converter; var result d.Convertint(input); // 編譯錯誤編譯器會報錯因為dynamic調(diào)用不支持顯式指定泛型類型參數(shù)。如果想實現(xiàn)類似效果只能走反射var method converter.GetType().GetMethod(Convert).MakeGenericMethod(typeof(int)); var result method.Invoke(converter, new object[] { input });這種場景反射反而不慢——因為方法信息可以緩存起來但dynamic在語法上直接沒有入口。遇到泛型動態(tài)調(diào)用的需求別死磕dynamic。5.3 坑三私有成員、內(nèi)部成員、擴(kuò)展方法綁定器的“盲區(qū)”DLR綁定器遵循普通C#成員可見性規(guī)則。d.PrivateMethod()直接拋Microsoft.CSharp.RuntimeBinder.RuntimeBinderExceptioninternal成員在不同程序集里也一樣。這種情況用dynamic連編譯期錯誤都換不來純增加運(yùn)行時排查成本。還有一個大坑擴(kuò)展方法不參與動態(tài)綁定。d.Where(x x 0)如果d是dynamic編譯器不會去搜索靜態(tài)擴(kuò)展類上的方法而是嘗試在d的運(yùn)行時類型實例方法上找Where大概率拋異常。解決辦法是先把dynamic轉(zhuǎn)成IEnumerableT之類的靜態(tài)接口再調(diào)用擴(kuò)展方法。5.4 坑四重載決議在運(yùn)行時“偷偷變卦”C#的靜態(tài)重載決議是編譯期確定的dynamic則是運(yùn)行時按實際類型重新選一遍。void Foo(int x) { Console.WriteLine(int); } void Foo(string x) { Console.WriteLine(string); } object obj 42; dynamic d obj; Foo(d); // 運(yùn)行時解析為 Foo(int)表面上看沒問題。但當(dāng)你動態(tài)調(diào)用一個類的方法時如果傳入的實參運(yùn)行時類型和你預(yù)期不一樣可能選到完全不同的重載調(diào)試起來非常痛苦。因為編譯器不會幫你檢查只有跑到那行才暴露出來。我的經(jīng)驗是dynamic調(diào)用點不要包裹在復(fù)雜的重載鏈中能先聲明成具體類型就先轉(zhuǎn)具體類型否則潛在的重載選擇問題會像地雷一樣埋在代碼里。5.5 坑五值類型裝箱、結(jié)構(gòu)體大對象、規(guī)則爆炸dynamic本質(zhì)上是把任何類型包裝成object處理值類型每次賦值、訪問都涉及裝箱拆箱。如果代碼在循環(huán)里反復(fù)操作ListGuid、byte[]這類高密度數(shù)據(jù)dynamic的性能優(yōu)勢會被裝箱開銷抵消甚至反噬。更隱蔽的是“規(guī)則爆炸”。同一個CallSite上如果被傳入多種不同類型的參數(shù)對象DLR會頻繁生成新規(guī)則緩存空間被撐滿后規(guī)則可能被反復(fù)淘汰重建。在“異構(gòu)集合”的循環(huán)里用dynamic性能可能比反射還拉胯。Listobject mixed new Listobject { new Person(), new Car(), new Order() }; foreach (var item in mixed) { dynamic d item; d.Name ; // 每次觸發(fā)重新綁定 }這種代碼就該考慮用接口統(tǒng)一抽象而不是靠dynamic硬撐。DLR的緩存機(jī)制決定了“對相同類型做重復(fù)調(diào)用”才是最佳使用姿勢。5.6 坑六AOT/Trim環(huán)境下直接廢掉如果你未來要把項目切到NativeAOT或者發(fā)布到iOS這類不允許JIT的環(huán)境dynamic一定要提前排查。NativeAOT在編譯期需要靜態(tài)分析所有代碼路徑但DLR需要在運(yùn)行時動態(tài)生成和編譯表達(dá)式兩者根本矛盾。真實表現(xiàn)是編譯期可能就報錯或者發(fā)布后在dynamic調(diào)用點直接崩潰。相比之下反射在AOT下雖然也有裁剪風(fēng)險但配合DynamicDependency等特性還有挽回余地。如果目標(biāo)是AOTdynamic不是一個值得冒險的方案。5.7 坑七異常信息、排查成本與編譯期保護(hù)的缺失dynamic把“編譯期檢查”變成了“運(yùn)行時綁定”。屬性名拼錯不會在編譯期報錯而是運(yùn)行到那行直接拋RuntimeBinderException。這還不是最痛的點——真正的痛在于RuntimeBinderException的調(diào)用棧信息在多重動態(tài)調(diào)用鏈中經(jīng)常只顯示入口定位“哪個屬性名錯了”要靠日志和局部變量觀察。dynamic調(diào)用里面的方法拋出異常不會像反射那樣包一層TargetInvocationException而是直接把原始異常拋出來乍一看少了干擾項但如果你習(xí)慣了反射的異常模式很容易誤判調(diào)用位置。大規(guī)模重構(gòu)時改一個屬性名項目里的dynamic調(diào)用點不會像靜態(tài)代碼那樣報編譯錯誤只有在測試跑到的路徑上才會崩。我的補(bǔ)救手段dynamic調(diào)用點強(qiáng)制包一層帶上下文的try-catch日志里記錄當(dāng)前對象類型和調(diào)用的成員名至少要留出可排查的尾巴。5.8 一張表收尾動態(tài)/反射各場景選型對照使用場景推薦方案理由循環(huán)內(nèi)按已知屬性名/方法名調(diào)用dynamic自動緩存規(guī)則性能好代碼少運(yùn)行時才知道成員名字符串反射PropertyInfo緩存dynamic語法不支持字符串成員名調(diào)用未知類型的公共接口方法dynamic省去接口轉(zhuǎn)換和反射樣板私有/內(nèi)部成員訪問反射dynamic綁定器不透明訪問非公共成員泛型方法且需指定泛型參數(shù)反射 MakeGenericMethoddynamic無法顯式指定泛型參數(shù)COM/Office互操作dynamic語法簡潔設(shè)計初衷NativeAOT發(fā)布場景反射配合AOT特性DLR不兼容AOT異構(gòu)對象集合中批量調(diào)用同名方法接口/基類抽象避免規(guī)則爆炸和反復(fù)綁定6. dynamic之外的下一步6.1 表達(dá)式樹編譯委托動態(tài)調(diào)用的性能天花板如果某項動態(tài)調(diào)用是系統(tǒng)瓶頸而且你能預(yù)知方法的簽名比如固定參數(shù)個數(shù)、固定參數(shù)類型最暴力的優(yōu)化是用表達(dá)式樹編譯一個強(qiáng)類型委托緩存起來public static Funcobject, string BuildGetter(Object target, string propertyName) { var param Expression.Parameter(typeof(object), target); var cast Expression.Convert(param, target.GetType()); var property Expression.Property(cast, propertyName); var convert Expression.Convert(property, typeof(string)); return Expression.LambdaFuncobject, string(convert, param).Compile(); }這樣每次調(diào)用只做一次類型轉(zhuǎn)換和屬性讀取性能比dynamic更高適合“框架化、重復(fù)調(diào)用頻率極高”的路徑。代價是代碼明顯復(fù)雜而且一旦遇到方法重載、泛型參數(shù)、可選參數(shù)表達(dá)式樹的復(fù)雜度會指數(shù)級上升。所以我的排序是簡單場景用dynamic瓶頸場景上表達(dá)式樹一般場景別亂折騰。6.2 用接口、基類、設(shè)計模式代替動態(tài)很多動態(tài)需求其實是設(shè)計缺陷的信號。如果一個集合里有Person、Car、Order都要讀取Name屬性為什么不定義INamed接口如果插件系統(tǒng)里所有插件都有Execute()為什么不抽象一個公共接口我在優(yōu)化老項目時發(fā)現(xiàn)動態(tài)調(diào)用或反射代碼密集的地方往往是當(dāng)年圖省事、繞過了類型設(shè)計的地方。能用接口解決的設(shè)計問題不要用dynamic補(bǔ)。dynamic應(yīng)該是“類型系統(tǒng)表達(dá)不了的場景”的補(bǔ)充手段而不是常規(guī)武器。6.3 個人在實際優(yōu)化中的體會我復(fù)盤這次Excel導(dǎo)出優(yōu)化最大的感慨是性能優(yōu)化前先搞清楚技術(shù)方案的真實能力邊界。我原本也默認(rèn)dynamic就是慢結(jié)果實測下來它在“同類型高頻重復(fù)調(diào)用”場景里吊打反射和直接調(diào)用差距已經(jīng)微乎其微。這幾年C#的運(yùn)行時也在持續(xù)改進(jìn).NET Core時代的DLR實現(xiàn)相比.NET Framework已經(jīng)有明顯進(jìn)步再用十年前的印象給dynamic判死刑真的說不過去。如果你也要動這類代碼我給你三個可直接落地的忠告先寫一小段基準(zhǔn)測試把你的真實業(yè)務(wù)場景跑出數(shù)據(jù)再決定改哪些點。不要聽任何人說“dynamic快”或“dynamic慢”就直接上結(jié)論。改動只覆蓋熱路徑非熱路徑保持原樣。我這次只改了最內(nèi)層循環(huán)里那兩行反射取值外層邏輯一概沒動回歸成本極低。動態(tài)調(diào)用點一定要有日志和異常上下文不然線上出了問題排查時間可能比省下的那幾秒導(dǎo)出時間貴得多。技術(shù)的鍋往往是使用姿勢的鍋。dynamic背了十幾年的黑鍋也該在真實數(shù)據(jù)面前翻身了。