请写一篇关于【MyBatis基础教程：Java持久层框架入门】的技术文章
上周五晚上10点47分，我瘫在浦东张江某老破小合租房的沙发上，左手捏着半凉的外卖盒饭，右手疯狂敲键盘。女朋友在隔壁房间戴着降噪耳机打《原神》，而我——一个背着6800块月供、挤2小时地铁上下班的北漂（哦不对，是沪漂）Java程序员——正在为明天上线的项目紧急修一个SQL注入漏洞。
“又是MyBatis没用好。”我盯着IDEA里那行手拼的SQL字符串，心里骂了一句。这已经是本月第三次了。项目经理老王今早还阴阳怪气地说：“你们后端能不能学学前同事？人家用Python Flask三天搭完API，你这Java项目光配XML就搞一周？”
说实话，那一刻我真的有点破防。月薪从15k涨到22k是不错，但房租3500、房贷6800、通勤卡每月260……剩下的钱连给女友买杯喜茶都要算计。而更扎心的是，技术栈好像越来越“过时”了。
为什么我还在死磕MyBatis？
先说清楚：我不是不想转Python或JavaScript。去年十月，我甚至偷偷报了个全栈训练营，白天写Java，晚上啃Vue3 + Node.js。结果坚持两周就放弃了——不是学不会，是没精力。每天挤地铁两小时，到家只想躺平。女友劝我：“要不换个小公司？压力小点。”我苦笑：“小公司不用MyBatis，用JPA或者干脆上MongoDB，但我简历上全是SSM，跳槽面大厂还得靠这个。”
现实就是这么骨感。国内中大型企业，尤其是金融、政务、传统电商这些“现金流稳定”的领域，Java + MyBatis 组合依然是铁打的标配。你可以说它老土，但它的生态稳如老狗。
MyBatis到底是个啥？别被术语吓住
简单说，MyBatis 是一个 Java 的持久层框架，作用就是帮你把 Java 对象和数据库记录之间“翻译”一下，省得你手写 JDBC 那堆 try-catch-close 的垃圾代码。
举个最直白的例子：
没有 MyBatis 时，你要查一个用户：
Connection conn = DriverManager.getConnection(...);
PreparedStatement ps = conn.prepareStatement("SELECT * FROM user WHERE id = ?");
ps.setInt(1, userId);
ResultSet rs = ps.executeQuery();
// 然后一行行 rs.getString()...
用了 MyBatis 后，你只需要写个接口：
public interface UserMapper {
User selectUserById(int id);
}
再配个 XML（或者注解）：
<select id="selectUserById" resultType="User">
SELECT * FROM user WHERE id = #{id}
</select>
搞定。SQL 和 Java 代码分离，清晰又安全。
别人用 Python 写三行，我写三十行？值不值？
前几天和前端组的小李吃饭，他炫耀自己用 JavaScript + Express 写了个后台管理API，前后端联调只花半天。“你们Java是不是太重了？”他问。
我反问他：“你那个系统要扛住5000并发吗？要做二级缓存吗？要对接Oracle老库吗？要审计每条SQL执行时间吗？”
他沉默了。
MyBatis 的优势不在“快”，而在“可控”。Python 的 SQLAlchemy 或 Django ORM 很爽，但一旦 SQL 复杂（比如多表关联 + 分页 + 动态条件），你就得写原生 SQL，反而更乱。而 MyBatis 从设计上就鼓励你写 SQL —— 它不替你生成，而是让你专注优化 SQL 本身。
上周那个漏洞，根源就是有人图快，用 ${} 拼接参数（相当于直接插字符串），而不是用 #{}（预编译）。换成 Python 的 f-string 拼 SQL，一样中招。语言不背锅，人背锅。
前端都上 React 了，后端还在 XML 里挣扎？
确实，现在新项目越来越多用注解替代 XML。比如：
@Select("SELECT * FROM user WHERE name = #{name}")
List<User> findByName(@Param("name") String name);
但别急着嘲笑 XML 老土。复杂查询（比如带 <if>、<foreach> 的动态 SQL），XML 的可读性远胜注解。而且，MyBatis-Plus 这种增强工具已经让 CRUD 简化到离谱：
userMapper.selectById(123); // 自动生成SQL
userMapper.selectList(new QueryWrapper<User>().eq("age", 25));
所以，别一听到“XML配置”就摇头。真正的痛点从来不是技术，而是团队有没有规范。我现在的项目，强制要求所有 SQL 走 MyBatis，禁止手拼；Mapper 方法命名必须语义清晰；Git 提交前 Sonar 扫描……这才叫工程化。
给同样挣扎的你几点建议
别盲目追新。Python/JS 确实香，但如果你在 Java 生态里混，先把 MyBatis 吃透。面试官问“#{} 和 ${} 区别”，答不上来直接挂。
善用工具链。IntelliJ IDEA 装 MyBatisX 插件，XML 和 Mapper 接口一键跳转；配合 Lombok，POJO 代码少写80%。
和前端对齐思维。现在很多后端也要懂点前端。我们项目用 Vue3 + Axios 调 MyBatis 接口，约定好 RESTful 规范（比如 GET /users/{id}），联调效率翻倍。
别怕“老技术”。MyBatis 2001年诞生，但它每年都在进化。最新版支持 Java 17、响应式编程（MyBatis-R2DBC）、甚至能和 Spring Boot 3 无缝集成。
最后：技术人的体面，是把工具用到极致
昨天深夜，我又一次改完 Bug 提交代码。女友探头问：“还不睡？”
我说：“马上。刚把那个SQL改成 #{} 了。”
她笑：“你啊，跟你的 MyBatis 过日子吧。”
我回她：“总比跟房贷过日子强。”
其实我知道，无论用 Java、Python 还是 JavaScript，核心能力从来不是语言本身，而是解决问题的思路。MyBatis 只是个工具，但它教会我一件事：在混乱的业务需求中，保持数据访问层的清晰与安全，是对团队最基本的尊重。
也许哪天我会转 Go，会玩 Rust，甚至真去搞全栈。但在那之前，我得先把眼前的项目跑稳，把房贷还清，把地铁挤明白。
毕竟，在上海这座城，能稳稳地活着，就已经赢了一半。
共勉：技术会过时，但扎实的基本功永远不会。你手里的 MyBatis，或许就是下一份 offer 的敲门砖。
评论 0