场景

复杂查询需要精确 SQL 控制时，MyBatis 很合适；但参数拼接、结果映射、缓存和会话边界处理不当，也容易产生注入、N+1 或脏数据。

原理

配置会把 Mapper 声明解析为映射语句，代理对象接收方法调用，经 Executor、StatementHandler、ParameterHandler 与 ResultSetHandler 完成执行和映射。SqlSession 非线程安全，一级缓存跟随会话，二级缓存跨会话且需谨慎维护一致性。

设计步骤

先把 SQL 与参数契约写清，值使用 #{} 绑定，${} 只用于经过白名单的结构片段；复杂映射显式使用 resultMap；关联数据优先批量查询；事务由服务层定义；最后用执行计划、慢日志和真实数据量验证性能。

权衡

MyBatis 可控且透明，但样板代码和 SQL 维护成本高；延迟加载减少初次查询，却可能隐藏 N+1；二级缓存降低读压，却在多表更新和分布式环境中带来失效难题；插件强大但会改变全局链路。

实践建议

Mapper 保持无状态，分页必须有稳定排序；批处理控制批次和事务大小；大结果集使用游标并及时关闭资源。不要为了复用拼出难读的动态 SQL。排障按参数、最终 SQL、执行计划、映射、事务提交顺序进行，比盲目加缓存可靠。

落地检查

上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的返回、日志和指标彼此对应；在预发布环境模拟依赖不可用、进程重启和配置回滚，验证降级路径不会放大故障。上线时采用小流量观察，提前定义停止条件与负责人。稳定后复盘真实数据，删除没有收益的复杂度，并把新发现的约束补进测试、监控和设计记录，使方案能够随业务持续演进，而不是停留在一次性评审结论。