MyBatis结果集映射机制详解：解决物理字段与逻辑属性不匹配的Null异常
字段命名差异导致的数据回空问题
在企业级应用开发中，关系型数据库的物理表结构与面向对象领域的实体模型往往采用不同的命名规范。这种差异直接导致了持久化框架在执行标准查询时出现部分属性值为null的现象。MyBatis默认遵循反射机制将数据库列名转换为小写，随后在目标类中寻找对应的Setter方法。若找不到匹配的方法签名，该字段将被跳过赋值。
以下通过一个账户管理模块演示典型场景。假设底层存储采用如下表结构：
对应的业务领域对象定义了截然不同的属性标识：
public class AccountEntity {
private Long accountId; // 期望映射 acc_id
private String loginName; // 期望映射 usr_login
private String authSecret; // 实际库列为 pwd_hash，此处发生偏移
// 省略构造方法、Getter/Setter及toString实现
}数据访问接口定义：
public interface AccountMapper {
AccountEntity queryAccountByPk(Long uid);
}初始映射配置依赖类型推断：
<select id="queryAccountByPk" resultType="com.example.AccountEntity">
SELECT * FROM t_sys_account WHERE acc_id = #{uid}
</select>执行单元测试验证：
@Test
void testAccountQuery() {
try (SqlSession session = SqlSessionFactoryUtil.getSession()) {
AccountMapper dao = session.getMapper(AccountMapper.class);
AccountEntity entity = dao.queryAccountByPk(1L);
System.out.println(entity);
}
}运行结果显示authSecret返回空值。根本原因在于底层执行的SQL等价于SELECT acc_id, usr_login, pwd_hash ...。框架内部转换列名为小写后尝试调用setAuthsecret()或setAuth_secret()进行绑定，但由于物理列名为pwd_hash，反射链路断裂，最终导致局部数据丢失。此即MyBatis默认的隐式自动映射行为。
差异化映射解决方案
方案一：SQL层别名对齐
在查询语句中直接使用别名修正输出元数据，使其严格匹配JavaBean规范：
<select id="queryAccountByPk" resultType="AccountEntity">
SELECT acc_id, usr_login, pwd_hash AS authSecret FROM t_sys_account WHERE acc_id = #{uid}
</select>修复后数据完整回显：
方案二：基于ResultMap的显式声明（推荐）
过度依赖SQL别名会在复杂的多表联查中造成语句臃肿且难以维护。MyBatis提供了专用的配置节点，用于解耦物理存储布局与逻辑对象模型：
<resultMap id="AccountDef" type="com.example.AccountEntity">
<!-- 主键专用标识 -->
<id column="acc_id" property="accountId"/>
<!-- 普通列映射规则 -->
<result column="usr_login" property="loginName"/>
<result column="pwd_hash" property="authSecret"/>
</resultMap>
<select id="queryAccountByPk" resultMap="AccountDef">
SELECT acc_id, usr_login, pwd_hash FROM t_sys_account WHERE acc_id = #{uid}
</select>验证日志表明通过外部契约定义同样能够稳定完成装配：
ResultMap 核心设计思想
作为持久层抽象的核心组件，ResultMap旨在彻底剥离繁琐的JDBC结果集遍历代码。面对涉及多表关联的复杂查询场景，一份结构化的映射配置即可替代数千行样板赋值逻辑。
隐式自动映射机制
在常规业务流中，开发者极少需要手动干预映射过程。框架默认采用约定优于配置的策略。例如以下精简片段：
<select id="basicRetrieve" resultType="map">
SELECT acc_id, usr_login, pwd_hash FROM t_sys_account LIMIT 1
</select>上述配置利用resultType将全量列自动灌入哈希集合。尽管能满足临时报表需求，但原生映射缺乏类型安全性约束。现代架构普遍偏好强类型的POJO载体。值得说明的是，该框架的智能之处在于：即便你尚未深入掌握映射语法，基础场景依然可以零配置运行。
显式手动映射流程
启用自定义契约需将指令从resultType切换至resultMap。整体实施步骤如下：
注册检索动作并指向映射ID：
<select id="queryAccountByPk" resultMap="AccountDef">
SELECT acc_id, usr_login, pwd_hash FROM t_sys_account WHERE acc_id = #{uid}
</select>构建转换蓝图：
<resultMap id="AccountDef" type="com.example.AccountEntity">
<id column="acc_id" property="accountId"/>
<result column="usr_login" property="loginName"/>
<result column="pwd_hash" property="authSecret"/>
</resultMap>扁平化的单表映射仅需少量声明即可完成对接。然而实际项目中广泛存在父子层级与集合聚合关系。针对此类复杂拓扑，后续将引入<association>与<collection>等高级聚合节点进行嵌套组装与延迟加载优化。
