1. 一個(gè)現(xiàn)象引發(fā)的思考好用與普及度的背離最近在幾個(gè)技術(shù)社區(qū)和項(xiàng)目群里發(fā)現(xiàn)一個(gè)挺有意思的現(xiàn)象。大家討論持久層框架時(shí)MyBatis-Plus簡(jiǎn)稱MP的口碑普遍不錯(cuò)很多用過的人都會(huì)說一句“真香”功能封裝得貼心開發(fā)效率提升明顯。但當(dāng)你把視線投向公司里正在運(yùn)行的老項(xiàng)目或者去翻看一些主流開源項(xiàng)目的技術(shù)棧時(shí)又會(huì)發(fā)現(xiàn)純“裸奔”的MyBatis或者搭配各種自制工具類的組合依然占據(jù)著相當(dāng)大的比例。MP似乎并沒有像它的口碑那樣實(shí)現(xiàn)同等程度的普及。這個(gè)“叫好不叫座”的落差就引出了我們今天的核心話題為什么一個(gè)被公認(rèn)為“好用”的工具在實(shí)際的、大規(guī)模的生產(chǎn)應(yīng)用選擇中反而顯得“用的不多”這里說的“用的不多”是一個(gè)相對(duì)概念。并不是指完全沒人用事實(shí)上MP擁有龐大的用戶群和活躍的社區(qū)。而是指相對(duì)于其提供的便利性和“好用”的評(píng)價(jià)它在企業(yè)級(jí)、尤其是中大型、歷史包袱較重的項(xiàng)目中的滲透率可能并沒有我們想象中那么高。這種背離背后往往不是技術(shù)優(yōu)劣的簡(jiǎn)單評(píng)判而是一系列技術(shù)決策、團(tuán)隊(duì)習(xí)慣、項(xiàng)目上下文和長(zhǎng)期維護(hù)成本等復(fù)雜因素交織的結(jié)果。今天我就結(jié)合自己這些年接觸過的各種項(xiàng)目從幾個(gè)不那么“技術(shù)”但非?！艾F(xiàn)實(shí)”的角度來拆解一下這個(gè)現(xiàn)象背后的邏輯。2. 歷史包袱與路徑依賴存量項(xiàng)目的巨大慣性當(dāng)我們談?wù)撘粋€(gè)新技術(shù)或新框架的“普及”時(shí)最容易忽略的就是已經(jīng)存在的、正在線上穩(wěn)定運(yùn)行的“存量項(xiàng)目”。這些項(xiàng)目構(gòu)成了技術(shù)生態(tài)的基底它們的框架選型往往具有強(qiáng)大的慣性。2.1 “能跑就別動(dòng)”的運(yùn)維鐵律對(duì)于任何一個(gè)已經(jīng)上線的、尤其是核心業(yè)務(wù)系統(tǒng)最高優(yōu)先級(jí)永遠(yuǎn)是“穩(wěn)定”。任何框架的變更尤其是像持久層這樣涉及數(shù)據(jù)生命核心的組件都意味著巨大的風(fēng)險(xiǎn)和測(cè)試成本。一個(gè)使用原生MyBatis多年的項(xiàng)目其Mapper.xml文件可能成千上萬(wàn)其中充滿了各種復(fù)雜的動(dòng)態(tài)SQL、特定的數(shù)據(jù)庫(kù)方言優(yōu)化、以及歷史遺留的“黑魔法”寫法。這些代碼經(jīng)過多年業(yè)務(wù)迭代和線上考驗(yàn)雖然可能不優(yōu)雅但足夠穩(wěn)定。此時(shí)引入MP意味著什么首先團(tuán)隊(duì)需要評(píng)估將現(xiàn)有Mapper.xml中的邏輯尤其是復(fù)雜查詢遷移到MP的Wrapper或自定義SQL片段模式下的成本和風(fēng)險(xiǎn)。這個(gè)遷移過程絕非簡(jiǎn)單的替換它涉及到思維模式的轉(zhuǎn)換和潛在的性能差異驗(yàn)證。其次MP的很多特性如自動(dòng)填充、邏輯刪除、樂觀鎖等在存量數(shù)據(jù)模型上啟用需要仔細(xì)的數(shù)據(jù)兼容性設(shè)計(jì)和數(shù)據(jù)遷移方案稍有不慎就會(huì)導(dǎo)致數(shù)據(jù)錯(cuò)亂。對(duì)于運(yùn)維和項(xiàng)目負(fù)責(zé)人來說為一個(gè)運(yùn)行良好的系統(tǒng)引入一個(gè)不確定的變更其ROI投資回報(bào)率往往是負(fù)的。因此“既然MyBatis用得好好的何必折騰”就成了最主流也最務(wù)實(shí)的選擇。2.2 團(tuán)隊(duì)知識(shí)結(jié)構(gòu)的鎖定一個(gè)技術(shù)棧的長(zhǎng)期使用會(huì)在團(tuán)隊(duì)中形成強(qiáng)大的“肌肉記憶”和知識(shí)結(jié)構(gòu)鎖定。開發(fā)人員對(duì)原生MyBatis的配置、SqlSession生命周期、插件機(jī)制、緩存原理等已經(jīng)爛熟于心遇到問題能夠快速定位和解決。團(tuán)隊(duì)內(nèi)部也積累了大量針對(duì)原生MyBatis的最佳實(shí)踐、代碼模板和排錯(cuò)手冊(cè)。引入MP相當(dāng)于要求整個(gè)團(tuán)隊(duì)學(xué)習(xí)一套新的API和設(shè)計(jì)理念。雖然MP的學(xué)習(xí)成本不高但對(duì)于一個(gè)任務(wù)飽和的團(tuán)隊(duì)來說組織培訓(xùn)、統(tǒng)一新的開發(fā)規(guī)范、解決新舊寫法混用帶來的風(fēng)格不一致問題都需要額外的管理和協(xié)調(diào)成本。在項(xiàng)目壓力大的時(shí)候團(tuán)隊(duì)更傾向于使用最熟悉、風(fēng)險(xiǎn)最可控的工具而不是去擁抱一個(gè)雖然更好但需要學(xué)習(xí)的新事物。這種由“熟悉度”帶來的安全感是技術(shù)選型中一個(gè)非常關(guān)鍵的非技術(shù)因素。3. 靈活性與“黑盒”的權(quán)衡被封印的底層控制力MyBatis的核心魅力之一在于它在提供對(duì)象-關(guān)系映射ORM便利的同時(shí)沒有完全屏蔽開發(fā)者對(duì)SQL的控制權(quán)。你可以編寫任意復(fù)雜度的SQL并精確地控制其執(zhí)行行為。這種“半自動(dòng)化”的定位讓它在處理復(fù)雜業(yè)務(wù)、需要極致優(yōu)化時(shí)游刃有余。3.1 MP的封裝與個(gè)性化需求的沖突MP通過Wrapper等機(jī)制極大地簡(jiǎn)化了條件查詢的操作這是它“好用”的關(guān)鍵。但這種封裝在帶來便利的同時(shí)也筑起了一道墻。當(dāng)你需要一個(gè)非常復(fù)雜、涉及多重嵌套子查詢、特殊數(shù)據(jù)庫(kù)函數(shù)或優(yōu)化器提示Hint的SQL時(shí)Wrapper的鏈?zhǔn)秸{(diào)用可能會(huì)變得笨拙甚至無(wú)法表達(dá)。雖然MP保留了在Select注解或XML中編寫原生SQL的能力但這又回到了“半原生”的狀態(tài)使得MP的核心價(jià)值在這個(gè)場(chǎng)景下打了折扣。更微妙的一點(diǎn)在于MP自動(dòng)生成的SQL雖然能滿足90%的常見場(chǎng)景但其具體的生成邏輯對(duì)開發(fā)者而言是一個(gè)“灰盒”。例如它如何處理in查詢的批量分割默認(rèn)的批量操作事務(wù)邊界在哪里某些Wrapper組合會(huì)不會(huì)生成非預(yù)期的笛卡爾積當(dāng)出現(xiàn)性能問題時(shí)你排查的起點(diǎn)是MP生成的SQL而不是你親手寫的SQL這中間多了一層理解成本。對(duì)于追求極致性能和可控性的團(tuán)隊(duì)他們可能更愿意自己編寫和維護(hù)那些關(guān)鍵的復(fù)雜SQL以確保對(duì)執(zhí)行計(jì)劃的完全掌控。3.2 插件體系與自定義擴(kuò)展的復(fù)雜度原生MyBatis的插件Interceptor機(jī)制非常強(qiáng)大且相對(duì)直觀可以攔截Executor、StatementHandler、ParameterHandler、ResultSetHandler四大核心組件實(shí)現(xiàn)分頁(yè)、慢SQL日志、數(shù)據(jù)加解密等通用功能。很多公司都有自己深度定制的MyBatis插件。MP自身也有一套插件體系如PaginationInnerInterceptor、OptimisticLockerInnerInterceptor但它是在MyBatis插件機(jī)制之上的再封裝。當(dāng)你需要集成公司自有的、或第三方的一些特殊插件時(shí)就需要考慮MP插件與原有插件的執(zhí)行順序、兼容性問題。調(diào)試一個(gè)由MP插件、公司自定義插件、以及MyBatis原生插件組成的鏈路其復(fù)雜度遠(yuǎn)高于一個(gè)單純的MyBatis插件棧。這種潛在的集成復(fù)雜度讓一些架構(gòu)比較復(fù)雜或插件依賴較多的項(xiàng)目對(duì)引入MP持謹(jǐn)慎態(tài)度。4. 項(xiàng)目規(guī)模與架構(gòu)風(fēng)格的適配問題“好用”是一個(gè)主觀感受它與項(xiàng)目上下文強(qiáng)相關(guān)。MP的諸多特性在不同規(guī)模和架構(gòu)風(fēng)格的項(xiàng)目中價(jià)值權(quán)重是不同的。4.1 超大型項(xiàng)目的“架構(gòu)約束”在超大型互聯(lián)網(wǎng)公司或復(fù)雜系統(tǒng)中持久層往往只是整個(gè)數(shù)據(jù)訪問層DAL的一部分。這類系統(tǒng)通常有更嚴(yán)格的架構(gòu)分層和規(guī)范。例如它們可能要求數(shù)據(jù)訪問層完全通過接口定義實(shí)現(xiàn)細(xì)節(jié)無(wú)論是MyBatis還是MP被封裝在獨(dú)立的模塊或倉(cāng)庫(kù)中對(duì)上層業(yè)務(wù)邏輯透明?；蛘咚鼈冇薪y(tǒng)一的數(shù)據(jù)庫(kù)中間件、分庫(kù)分表方案和監(jiān)控體系。在這種情況下MP提供的很多“開箱即用”的便利如自動(dòng)CRUD、Service層封裝可能與公司級(jí)的統(tǒng)一架構(gòu)規(guī)范沖突。架構(gòu)團(tuán)隊(duì)更傾向于提供一套標(biāo)準(zhǔn)化的、最低限度的MyBatis基礎(chǔ)模板和代碼生成器讓各個(gè)業(yè)務(wù)團(tuán)隊(duì)在此基礎(chǔ)上根據(jù)自身需求做有限擴(kuò)展而不是引入一個(gè)功能豐富但可能帶來額外約束的“全家桶”。MP的“強(qiáng)功能”特性在需要“弱約束”、“標(biāo)準(zhǔn)化”的超大體系內(nèi)有時(shí)反而成為一種負(fù)擔(dān)。4.2 “微服務(wù)”與“輕量化”語(yǔ)境下的考量在微服務(wù)架構(gòu)中服務(wù)粒度變小每個(gè)服務(wù)的業(yè)務(wù)邏輯和持久化操作相對(duì)單純。這時(shí)MP快速開發(fā)的優(yōu)勢(shì)確實(shí)能發(fā)揮出來。但另一方面微服務(wù)也強(qiáng)調(diào)技術(shù)的多樣性和選擇權(quán)。不同的服務(wù)團(tuán)隊(duì)根據(jù)服務(wù)特性和歷史原因可能會(huì)選擇不同的持久化方案有的用JPA有的用原生MyBatis有的用MP甚至有的直接用JdbcTemplate或更輕量的工具。如果一個(gè)團(tuán)隊(duì)已經(jīng)習(xí)慣了某一種模式并且該模式在微服務(wù)生態(tài)下如鏈路追蹤、SQL監(jiān)控集成運(yùn)作良好那么他們主動(dòng)切換到MP的動(dòng)力可能并不強(qiáng)烈。除非有強(qiáng)有力的全公司級(jí)技術(shù)棧統(tǒng)一要求否則“輕量化”和“團(tuán)隊(duì)自主權(quán)”的思潮會(huì)使得MP作為一種“增強(qiáng)型選項(xiàng)”而非“必選項(xiàng)”存在。5. 抽象泄漏與長(zhǎng)期維護(hù)的隱憂框架的抽象是為了簡(jiǎn)化但所有不完美的抽象都會(huì)發(fā)生“泄漏”。MP在隱藏了MyBatis很多細(xì)節(jié)的同時(shí)也可能會(huì)在特定場(chǎng)景下讓這些細(xì)節(jié)以更棘手的方式暴露出來。5.1 版本升級(jí)與兼容性風(fēng)險(xiǎn)MP是一個(gè)活躍迭代的項(xiàng)目它的版本更新可能會(huì)引入新特性、改變某些API的行為、或者修復(fù)一些底層Bug。對(duì)于深度依賴MP的項(xiàng)目版本升級(jí)需要經(jīng)過嚴(yán)格的測(cè)試。更麻煩的是MP的版本與MyBatis的版本、Spring Boot的版本之間存在依賴關(guān)系。這形成了一個(gè)“依賴矩陣”升級(jí)任何一個(gè)組件都可能需要聯(lián)動(dòng)測(cè)試。相比之下原生MyBatis的核心API非常穩(wěn)定版本升級(jí)帶來的 breaking change 風(fēng)險(xiǎn)較低。很多老項(xiàng)目可能常年使用MyBatis 3.4.x或3.5.x沒有任何升級(jí)壓力。使用MP則意味著你主動(dòng)選擇加入了一個(gè)更快速迭代的生態(tài)需要付出相應(yīng)的兼容性維護(hù)成本。對(duì)于追求極度穩(wěn)定的金融、電信等行業(yè)項(xiàng)目這種不確定性是他們極力避免的。5.2 復(fù)雜查詢?cè)诘械牧踊@是一個(gè)非常實(shí)際的開發(fā)體驗(yàn)問題。假設(shè)一個(gè)業(yè)務(wù)查詢最初很簡(jiǎn)單用MP的QueryWrapper幾行代碼就搞定。隨著業(yè)務(wù)發(fā)展查詢條件不斷增加Wrapper的鏈?zhǔn)秸{(diào)用可能變得越來越長(zhǎng)各種and、or、嵌套apply混雜在一起可讀性急劇下降。最終這段代碼可能變得難以理解和維護(hù)還不如一開始就寫在XML或注解里的原生SQL清晰。此時(shí)團(tuán)隊(duì)面臨一個(gè)重構(gòu)決策是將這個(gè)已經(jīng)變得復(fù)雜的Wrapper拆解、轉(zhuǎn)寫成原生SQL還是繼續(xù)在Wrapper的泥潭中添磚加瓦如果轉(zhuǎn)寫那么之前使用MP的價(jià)值在這個(gè)場(chǎng)景下就歸零了還額外增加了重構(gòu)成本。這種現(xiàn)象會(huì)導(dǎo)致項(xiàng)目中出現(xiàn)“MP代碼”和“原生代碼”的混合風(fēng)格長(zhǎng)期來看增加維護(hù)難度。因此有經(jīng)驗(yàn)的團(tuán)隊(duì)在項(xiàng)目啟動(dòng)時(shí)就會(huì)權(quán)衡對(duì)于預(yù)期會(huì)非常復(fù)雜的核心查詢是否從一開始就避免使用Wrapper從而保持代碼風(fēng)格的一致性。6. 認(rèn)知偏差與“技術(shù)選型錨點(diǎn)”最后我們來談?wù)勔恍┲饔^和認(rèn)知層面的因素。技術(shù)選型從來都不是純粹理性的。6.1 “正宗”與“衍生”的心理權(quán)重在很多人特別是資深工程師或架構(gòu)師心中MyBatis是Apache旗下的頂級(jí)項(xiàng)目是經(jīng)過無(wú)數(shù)大型項(xiàng)目考驗(yàn)的“正宗”持久層框架。而MyBatis-Plus是一個(gè)國(guó)內(nèi)個(gè)人/團(tuán)隊(duì)主導(dǎo)的、基于MyBatis的增強(qiáng)工具。這種“根正苗紅”與“優(yōu)秀衍生”的出身差異會(huì)在潛意識(shí)里影響決策。在選擇基礎(chǔ)技術(shù)棧時(shí)尤其是在為一項(xiàng)可能持續(xù)五年十年的核心系統(tǒng)做選型時(shí)決策者往往會(huì)傾向于選擇那個(gè)背景更深厚、生態(tài)更“標(biāo)準(zhǔn)”、社區(qū)支持指國(guó)際社區(qū)更廣泛的基礎(chǔ)組件。他們覺得這樣風(fēng)險(xiǎn)更低技術(shù)債務(wù)更少。MP雖然在國(guó)內(nèi)社區(qū)極其活躍但在這種“錨定效應(yīng)”下它可能被定位為“一個(gè)非常好的、可以在特定場(chǎng)景下采用的增強(qiáng)方案”而不是“默認(rèn)的、首選的持久層標(biāo)準(zhǔn)”。這種定位決定了它不會(huì)輕易取代原生MyBatis在架構(gòu)師心中的基準(zhǔn)位置。6.2 學(xué)習(xí)路徑與招聘市場(chǎng)的反饋對(duì)于新手而言學(xué)習(xí)MyBatis是學(xué)習(xí)Java持久層的一個(gè)標(biāo)準(zhǔn)步驟。幾乎所有教程、書籍、官方文檔都以原生MyBatis為核心。學(xué)會(huì)了MyBatis再去看MP會(huì)覺得事半功倍。反之如果直接學(xué)習(xí)MP雖然上手快但可能對(duì)MyBatis底層的機(jī)制如插件、一級(jí)/二級(jí)緩存、SqlSession理解不深。這種學(xué)習(xí)路徑反映在招聘市場(chǎng)上。Job Description里通常寫的是“熟悉MyBatis”而很少直接寫“熟悉MyBatis-Plus”。因?yàn)榍罢叽砹顺志脤拥幕A(chǔ)能力掌握了它無(wú)論公司用MP還是其他封裝開發(fā)者都能快速適應(yīng)。這種市場(chǎng)供需的反饋也無(wú)形中鞏固了原生MyBatis作為“必備技能”的地位使得MP更多地作為一種“錦上添花”的附加技能存在影響了它在企業(yè)中的基礎(chǔ)性普及。7. 結(jié)論MP的價(jià)值與理性采用策略所以回到最初的問題MyBatis-Plus好用嗎答案是肯定的。它在CRUD操作、條件構(gòu)造、代碼生成、通用功能封裝等方面顯著提升了開發(fā)效率降低了樣板代碼讓開發(fā)者能更專注于業(yè)務(wù)邏輯。那為什么“用的不多”相對(duì)其口碑因?yàn)檫@把“好用的錘子”并不是所有場(chǎng)景下的“最優(yōu)解”。它的普及度受到了歷史項(xiàng)目遷移成本、團(tuán)隊(duì)路徑依賴、對(duì)底層SQL控制權(quán)的需求、復(fù)雜項(xiàng)目架構(gòu)約束、長(zhǎng)期維護(hù)風(fēng)險(xiǎn)以及一些非技術(shù)認(rèn)知因素的共同制約。對(duì)于新項(xiàng)目和技術(shù)決策者而言理性的做法不是二選一而是基于具體場(chǎng)景做權(quán)衡對(duì)于全新的、業(yè)務(wù)中后臺(tái)、CRUD密集型、團(tuán)隊(duì)想快速上手的項(xiàng)目MP幾乎是絕佳選擇能極大提升前期開發(fā)效率。對(duì)于預(yù)期有大量復(fù)雜SQL、對(duì)性能有極致要求、或需要與復(fù)雜現(xiàn)有架構(gòu)集成的項(xiàng)目謹(jǐn)慎評(píng)估MP的封裝帶來的靈活性損失可以考慮以原生MyBatis為主僅在簡(jiǎn)單場(chǎng)景下局部引入MP的某些特性如代碼生成器。對(duì)于存量老項(xiàng)目除非有強(qiáng)烈的、全面的重構(gòu)計(jì)劃否則局部修補(bǔ)勝于全局替換。不要為了用MP而用MP。最終一個(gè)工具的價(jià)值不在于它是否被最多的人使用而在于它是否在適合它的場(chǎng)景下被正確地使用并真正創(chuàng)造了價(jià)值。MyBatis-Plus的流行恰恰證明了市場(chǎng)對(duì)“提升MyBatis開發(fā)體驗(yàn)”的強(qiáng)烈需求。而它的相對(duì)“克制”的普及也反映了成熟技術(shù)生態(tài)中決策的復(fù)雜性和多樣性。作為開發(fā)者理解這背后的邏輯比單純爭(zhēng)論哪個(gè)更好要有意義得多。