小白上路，开车不稳之——Mybatis中使用查询语句SELECT进行编写，返回对象中个别数据为null
当遇到这个bug时，小白刚开始又以为自己写出bug，于是检查代码和SQL语句出错，反复检查后确定没有问题。且尝试更换别名id进行测试，发现结果可以输出，但是替换了自增主键id的值，尝试失败。思考一小时有余仍然没有头绪。于是上网搜索找类似问题，有关于实体类和返回结果不一致导致的，有说resultType和resultMap不能同时用的。最终发现本质原因在于mybatis中的返回结果使用的区别：即Resultmap和Resulttype的区别。
进mybatis官网发现这段话：（深邃难懂，不读三遍以上难以理解）
通过类型处理器的泛型，MyBatis 可以得知该类型处理器处理的 Java 类型，不过这种行为可以通过两种方法改变：
在类型处理器的配置元素（typeHandler 元素）上增加一个 javaType 属性（比如：javaType=“String”）；
在类型处理器的类上增加一个 @MappedTypes 注解指定与其关联的 Java 类型列表。 如果在 javaType
属性中也同时指定，则注解上的配置将被忽略。 可以通过两种方式来指定关联的 JDBC 类型：在类型处理器的配置元素上增加一个 jdbcType 属性（比如：jdbcType=“VARCHAR”）； 在类型处理器的类上增加一个
@MappedJdbcTypes 注解指定与其关联的 JDBC 类型列表。 如果在 jdbcType
属性中也同时指定，则注解上的配置将被忽略。 当在 ResultMap 中决定使用哪种类型处理器时，此时 Java
类型是已知的（从结果类型中获得），但是 JDBC 类型是未知的。 因此 Mybatis 使用 javaType=[Java 类型],
jdbcType=null 的组合来选择一个类型处理器。 这意味着使用 @MappedJdbcTypes
注解可以限制类型处理器的作用范围，并且可以确保，除非显式地设置，否则类型处理器在 ResultMap 中将不会生效。 如果希望能在
ResultMap 中隐式地使用类型处理器，那么设置 @MappedJdbcTypes 注解的
includeNullJdbcType=true 即可。 然而从 Mybatis 3.4.0 开始，如果某个 Java
类型只有一个注册的类型处理器，即使没有设置 includeNullJdbcType=true，那么这个类型处理器也会是 ResultMap
使用 Java 类型时的默认处理器。
个人理解就是（参考大佬心得）：
当返回类型属性是resultType时，mybatis默认结果封装成Map,一般默认resultType为Map集合中的key值，将返回结果作为value进行映射返回。当数据库返回结果和实体类中属性名一一对应时，可自动完成映射功能
当返回类型是resultMap时，Map进行更为复杂的转化，建议养成使用习惯。当数据库返回结果和实体类中属性名不对应时resultType可以使用resultMap自定义映射关系。
