1. 一个现象引发的思考：好用与普及度的背离
最近在几个技术社区和项目群里，发现一个挺有意思的现象。大家讨论持久层框架时，MyBatis-Plus（简称MP）的口碑普遍不错，很多用过的人都会说一句“真香”，功能封装得贴心，开发效率提升明显。但当你把视线投向公司里正在运行的老项目，或者去翻看一些主流开源项目的技术栈时，又会发现，纯“裸奔”的MyBatis，或者搭配各种自制工具类的组合，依然占据着相当大的比例。MP似乎并没有像它的口碑那样，实现同等程度的普及。这个“叫好不叫座”的落差，就引出了我们今天的核心话题：为什么一个被公认为“好用”的工具，在实际的、大规模的生产应用选择中，反而显得“用的不多”？
这里说的“用的不多”，是一个相对概念。并不是指完全没人用，事实上MP拥有庞大的用户群和活跃的社区。而是指，相对于其提供的便利性和“好用”的评价，它在企业级、尤其是中大型、历史包袱较重的项目中的渗透率，可能并没有我们想象中那么高。这种背离背后，往往不是技术优劣的简单评判，而是一系列技术决策、团队习惯、项目上下文和长期维护成本等复杂因素交织的结果。今天，我就结合自己这些年接触过的各种项目，从几个不那么“技术”，但非常“现实”的角度，来拆解一下这个现象背后的逻辑。
2. 历史包袱与路径依赖：存量项目的巨大惯性
当我们谈论一个新技术或新框架的“普及”时，最容易忽略的就是已经存在的、正在线上稳定运行的“存量项目”。这些项目构成了技术生态的基底，它们的框架选型，往往具有强大的惯性。
2.1 “能跑就别动”的运维铁律
对于任何一个已经上线的、尤其是核心业务系统，最高优先级永远是“稳定”。任何框架的变更，尤其是像持久层这样涉及数据生命核心的组件，都意味着巨大的风险和测试成本。一个使用原生MyBatis多年的项目，其Mapper.xml文件可能成千上万，其中充满了各种复杂的动态SQL、特定的数据库方言优化、以及历史遗留的“黑魔法”写法。这些代码经过多年业务迭代和线上考验，虽然可能不优雅，但足够稳定。
此时，引入MP意味着什么？首先，团队需要评估将现有Mapper.xml中的逻辑，尤其是复杂查询，迁移到MP的Wrapper或自定义SQL片段模式下的成本和风险。这个迁移过程绝非简单的替换，它涉及到思维模式的转换和潜在的性能差异验证。其次，MP的很多特性，如自动填充、逻辑删除、乐观锁等，在存量数据模型上启用，需要仔细的数据兼容性设计和数据迁移方案，稍有不慎就会导致数据错乱。对于运维和项目负责人来说，为一个运行良好的系统引入一个不确定的变更，其ROI（投资回报率）往往是负的。因此，“既然MyBatis用得好好的，何必折腾？”就成了最主流也最务实的选择。
2.2 团队知识结构的锁定
一个技术栈的长期使用，会在团队中形成强大的“肌肉记忆”和知识结构锁定。开发人员对原生MyBatis的配置、SqlSession生命周期、插件机制、缓存原理等已经烂熟于心，遇到问题能够快速定位和解决。团队内部也积累了大量针对原生MyBatis的最佳实践、代码模板和排错手册。
引入MP，相当于要求整个团队学习一套新的API和设计理念。虽然MP的学习成本不高，但对于一个任务饱和的团队来说，组织培训、统一新的开发规范、解决新旧写法混用带来的风格不一致问题，都需要额外的管理和协调成本。在项目压力大的时候，团队更倾向于使用最熟悉、风险最可控的工具，而不是去拥抱一个虽然更好但需要学习的新事物。这种由“熟悉度”带来的安全感，是技术选型中一个非常关键的非技术因素。
3. 灵活性与“黑盒”的权衡：被封印的底层控制力
MyBatis的核心魅力之一，在于它在提供对象-关系映射（ORM）便利的同时，没有完全屏蔽开发者对SQL的控制权。你可以编写任意复杂度的SQL，并精确地控制其执行行为。这种“半自动化”的定位，让它在处理复杂业务、需要极致优化时游刃有余。
3.1 MP的封装与个性化需求的冲突
MP通过Wrapper等机制，极大地简化了条件查询的操作，这是它“好用”的关键。但这种封装在带来便利的同时，也筑起了一道墙。当你需要一个非常复杂、涉及多重嵌套子查询、特殊数据库函数或优化器提示（Hint）的SQL时，Wrapper的链式调用可能会变得笨拙甚至无法表达。虽然MP保留了在@Select注解或XML中编写原生SQL的能力，但这又回到了“半原生”的状态，使得MP的核心价值在这个场景下打了折扣。
更微妙的一点在于，MP自动生成的SQL，虽然能满足90%的常见场景，但其具体的生成逻辑对开发者而言是一个“灰盒”。例如，它如何处理in查询的批量分割？默认的批量操作事务边界在哪里？某些Wrapper组合会不会生成非预期的笛卡尔积？当出现性能问题时，你排查的起点是MP生成的SQL，而不是你亲手写的SQL，这中间多了一层理解成本。对于追求极致性能和可控性的团队，他们可能更愿意自己编写和维护那些关键的复杂SQL，以确保对执行计划的完全掌控。
3.2 插件体系与自定义扩展的复杂度
原生MyBatis的插件（Interceptor）机制非常强大且相对直观，可以拦截Executor、StatementHandler、ParameterHandler、ResultSetHandler四大核心组件，实现分页、慢SQL日志、数据加解密等通用功能。很多公司都有自己深度定制的MyBatis插件。
MP自身也有一套插件体系（如PaginationInnerInterceptor、OptimisticLockerInnerInterceptor），但它是在MyBatis插件机制之上的再封装。当你需要集成公司自有的、或第三方的一些特殊插件时，就需要考虑MP插件与原有插件的执行顺序、兼容性问题。调试一个由MP插件、公司自定义插件、以及MyBatis原生插件组成的链路，其复杂度远高于一个单纯的MyBatis插件栈。这种潜在的集成复杂度，让一些架构比较复杂或插件依赖较多的项目对引入MP持谨慎态度。
4. 项目规模与架构风格的适配问题
“好用”是一个主观感受，它与项目上下文强相关。MP的诸多特性，在不同规模和架构风格的项目中，价值权重是不同的。
4.1 超大型项目的“架构约束”
在超大型互联网公司或复杂系统中，持久层往往只是整个数据访问层（DAL）的一部分。这类系统通常有更严格的架构分层和规范。例如，它们可能要求数据访问层完全通过接口定义，实现细节（无论是MyBatis还是MP）被封装在独立的模块或仓库中，对上层业务逻辑透明。或者，它们有统一的数据库中间件、分库分表方案和监控体系。
在这种情况下，MP提供的很多“开箱即用”的便利（如自动CRUD、Service层封装），可能与公司级的统一架构规范冲突。架构团队更倾向于提供一套标准化的、最低限度的MyBatis基础模板和代码生成器，让各个业务团队在此基础上根据自身需求做有限扩展，而不是引入一个功能丰富但可能带来额外约束的“全家桶”。MP的“强功能”特性，在需要“弱约束”、“标准化”的超大体系内，有时反而成为一种负担。
4.2 “微服务”与“轻量化”语境下的考量
在微服务架构中，服务粒度变小，每个服务的业务逻辑和持久化操作相对单纯。这时，MP快速开发的优势确实能发挥出来。但另一方面，微服务也强调技术的多样性和选择权。不同的服务团队，根据服务特性和历史原因，可能会选择不同的持久化方案：有的用JPA，有的用原生MyBatis，有的用MP，甚至有的直接用JdbcTemplate或更轻量的工具。
如果一个团队已经习惯了某一种模式，并且该模式在微服务生态下（如链路追踪、SQL监控集成）运作良好，那么他们主动切换到MP的动力可能并不强烈。除非有强有力的全公司级技术栈统一要求，否则“轻量化”和“团队自主权”的思潮，会使得MP作为一种“增强型选项”，而非“必选项”存在。
5. 抽象泄漏与长期维护的隐忧
框架的抽象是为了简化，但所有不完美的抽象都会发生“泄漏”。MP在隐藏了MyBatis很多细节的同时，也可能会在特定场景下让这些细节以更棘手的方式暴露出来。
5.1 版本升级与兼容性风险
MP是一个活跃迭代的项目，它的版本更新可能会引入新特性、改变某些API的行为、或者修复一些底层Bug。对于深度依赖MP的项目，版本升级需要经过严格的测试。更麻烦的是，MP的版本与MyBatis的版本、Spring Boot的版本之间存在依赖关系。这形成了一个“依赖矩阵”，升级任何一个组件都可能需要联动测试。
相比之下，原生MyBatis的核心API非常稳定，版本升级带来的 breaking change 风险较低。很多老项目可能常年使用MyBatis 3.4.x或3.5.x，没有任何升级压力。使用MP，则意味着你主动选择加入了一个更快速迭代的生态，需要付出相应的兼容性维护成本。对于追求极度稳定的金融、电信等行业项目，这种不确定性是他们极力避免的。
5.2 复杂查询在迭代中的劣化
这是一个非常实际的开发体验问题。假设一个业务查询，最初很简单，用MP的QueryWrapper几行代码就搞定。随着业务发展，查询条件不断增加，Wrapper的链式调用可能变得越来越长，各种and、or、嵌套apply混杂在一起，可读性急剧下降。最终，这段代码可能变得难以理解和维护，还不如一开始就写在XML或注解里的原生SQL清晰。
此时，团队面临一个重构决策：是将这个已经变得复杂的Wrapper拆解、转写成原生SQL，还是继续在Wrapper的泥潭中添砖加瓦？如果转写，那么之前使用MP的价值在这个场景下就归零了，还额外增加了重构成本。这种现象会导致项目中出现“MP代码”和“原生代码”的混合风格，长期来看增加维护难度。因此，有经验的团队在项目启动时就会权衡：对于预期会非常复杂的核心查询，是否从一开始就避免使用Wrapper，从而保持代码风格的一致性。
6. 认知偏差与“技术选型锚点”
最后，我们来谈谈一些主观和认知层面的因素。技术选型从来都不是纯粹理性的。
6.1 “正宗”与“衍生”的心理权重
在很多人，特别是资深工程师或架构师心中，MyBatis是Apache旗下的顶级项目，是经过无数大型项目考验的“正宗”持久层框架。而MyBatis-Plus是一个国内个人/团队主导的、基于MyBatis的增强工具。这种“根正苗红”与“优秀衍生”的出身差异，会在潜意识里影响决策。
在选择基础技术栈时，尤其是在为一项可能持续五年十年的核心系统做选型时，决策者往往会倾向于选择那个背景更深厚、生态更“标准”、社区支持（指国际社区）更广泛的基础组件。他们觉得这样风险更低，技术债务更少。MP虽然在国内社区极其活跃，但在这种“锚定效应”下，它可能被定位为“一个非常好的、可以在特定场景下采用的增强方案”，而不是“默认的、首选的持久层标准”。这种定位决定了它不会轻易取代原生MyBatis在架构师心中的基准位置。
6.2 学习路径与招聘市场的反馈
对于新手而言，学习MyBatis是学习Java持久层的一个标准步骤。几乎所有教程、书籍、官方文档都以原生MyBatis为核心。学会了MyBatis，再去看MP，会觉得事半功倍。反之，如果直接学习MP，虽然上手快，但可能对MyBatis底层的机制（如插件、一级/二级缓存、SqlSession）理解不深。
这种学习路径反映在招聘市场上。Job Description里通常写的是“熟悉MyBatis”，而很少直接写“熟悉MyBatis-Plus”。因为前者代表了持久层的基础能力，掌握了它，无论公司用MP还是其他封装，开发者都能快速适应。这种市场供需的反馈，也无形中巩固了原生MyBatis作为“必备技能”的地位，使得MP更多地作为一种“锦上添花”的附加技能存在，影响了它在企业中的基础性普及。
7. 结论：MP的价值与理性采用策略
所以，回到最初的问题，MyBatis-Plus好用吗？答案是肯定的。它在CRUD操作、条件构造、代码生成、通用功能封装等方面，显著提升了开发效率，降低了样板代码，让开发者能更专注于业务逻辑。
那为什么“用的不多”（相对其口碑）？因为这把“好用的锤子”，并不是所有场景下的“最优解”。它的普及度受到了历史项目迁移成本、团队路径依赖、对底层SQL控制权的需求、复杂项目架构约束、长期维护风险以及一些非技术认知因素的共同制约。
对于新项目和技术决策者而言，理性的做法不是二选一，而是基于具体场景做权衡：
- 对于全新的、业务中后台、CRUD密集型、团队想快速上手的项目，MP几乎是绝佳选择，能极大提升前期开发效率。
- 对于预期有大量复杂SQL、对性能有极致要求、或需要与复杂现有架构集成的项目，谨慎评估MP的封装带来的灵活性损失，可以考虑以原生MyBatis为主，仅在简单场景下局部引入MP的某些特性（如代码生成器）。
- 对于存量老项目，除非有强烈的、全面的重构计划，否则局部修补胜于全局替换。不要为了用MP而用MP。
最终，一个工具的价值不在于它是否被最多的人使用，而在于它是否在适合它的场景下，被正确地使用，并真正创造了价值。MyBatis-Plus的流行，恰恰证明了市场对“提升MyBatis开发体验”的强烈需求。而它的相对“克制”的普及，也反映了成熟技术生态中，决策的复杂性和多样性。作为开发者，理解这背后的逻辑，比单纯争论哪个更好，要有意义得多。
