MyBatis报错‘Error attempting to get column‘？别慌，先检查这三个地方（附Druid版本避坑）-编程阁

MyBatis报错'Error attempting to get column'？三步精准定位与高效修复指南

深夜11点，办公室只剩你的显示器还亮着。MyBatis突然抛出的Error attempting to get column 'start_time' from result set让原本即将提交的代码陷入僵局。这个看似简单的报错背后可能隐藏着字段映射、实体类构造或连接池版本等多重陷阱。本文将带你用黄金三步法快速定位问题根源，特别针对Druid与LocalDateTime的经典组合提供实战解决方案。

1. 第一步：字段映射检查 - 从表象到本质

当看到这个错误时，第一个反应应该是检查数据库字段与实体类属性的映射关系。但真正的专业排查远不止简单的名称比对：

// 典型MyBatis结果映射配置示例 <resultMap id="courseResultMap" type="com.example.Course"> <result property="startTime" column="start_time"/> <!-- 其他字段映射 --> </resultMap>

关键检查点：

驼峰命名是否开启自动转换（mybatis.configuration.map-underscore-to-camel-case=true）
字段类型是否匹配（如数据库DATETIME对应Java的LocalDateTime）
动态SQL中是否使用了错误的字段别名

提示：使用MyBatis的SQL日志功能（log4j.logger.org.mybatis=DEBUG）可以清晰看到最终执行的SQL和返回的列名

我曾遇到一个棘手案例：开发环境正常而生产环境报错，最终发现是SQL中使用了DATE_FORMAT(start_time, '%Y-%m-%d') as start_time导致类型信息丢失。这类问题需要：

对比数据库实际列名与resultMap配置
检查SQL中是否存在列重定义
验证TypeHandler是否注册正确

2. 第二步：实体类构造检查 - 隐藏在Lombok下的陷阱

字段映射正确却仍报错？接下来需要深入实体类内部机制。现代Java项目普遍使用Lombok简化代码，但这可能带来意想不到的问题：

@Data @Builder public class Course { private LocalDateTime startTime; // 其他字段... }

这段看似完美的代码实际上缺少无参构造器，而MyBatis实例化对象时依赖它。解决方案有两种：

方案A：显式添加无参构造器

@Data @Builder @NoArgsConstructor @AllArgsConstructor public class Course { private LocalDateTime startTime; }

方案B：自定义ObjectFactory

public class LombokAwareObjectFactory extends DefaultObjectFactory { @Override public <T> T create(Class<T> type) { if (type.isAnnotationPresent(Builder.class)) { try { return type.getMethod("builder").invoke(null).getClass() .getMethod("build").invoke(null); } catch (Exception e) { throw new RuntimeException(e); } } return super.create(type); } }

在mybatis-config.xml中配置：

<objectFactory type="com.example.LombokAwareObjectFactory"/>

3. 第三步：连接池版本排查 - Druid与LocalDateTime的恩怨情仇

当上述检查都通过却依然报错时，很可能是连接池作祟。特别是使用Druid+LocalDateTime组合时，版本选择至关重要：

Druid版本	LocalDateTime支持	推荐程度
<1.1.10	完全不支持	❌危险
1.1.10-1.1.23	部分支持	⚠️谨慎
≥1.2.0	完整支持	✅推荐

升级Druid的正确姿势：

修改pom.xml：

<dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-starter</artifactId> <version>1.2.8</version> </dependency>

检查兼容性：

// 验证代码 try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement("SELECT NOW()"); ResultSet rs = ps.executeQuery()) { if (rs.next()) { System.out.println("LocalDateTime支持测试: " + rs.getObject(1, LocalDateTime.class)); } }

回退方案（无法升级时）：

// 自定义TypeHandler处理字符串转换 public class LocalDateTimeFallbackHandler extends BaseTypeHandler<LocalDateTime> { @Override public LocalDateTime getNullableResult(ResultSet rs, String col) throws SQLException { String value = rs.getString(col); return value != null ? LocalDateTime.parse(value) : null; } // 其他必要方法实现... }

4. 高级防护：构建防御性编程实践

除了解决问题，更重要的是预防问题。以下是我在团队中推行的最佳实践：

防御性检查清单：

[ ] 在CI流程中加入MyBatis映射验证（使用mybatis-mapper-validator）
[ ] 统一Lombok使用规范（团队共享模板）
[ ] 关键TypeHandler的单元测试覆盖率≥80%
[ ] 新项目强制使用Druid 1.2.0+版本

监控方案：

// 通过AOP监控潜在问题 @Aspect @Component public class MyBatisMonitorAspect { @AfterThrowing( pointcut="execution(* org.mybatis.spring.SqlSessionTemplate.*(..))", throwing="ex") public void logMyBatisException(MyBatisSystemException ex) { if (ex.getMessage().contains("Error attempting to get column")) { alertToSlack("疑似字段映射异常: " + ex.getCause()); } } }

在微服务架构中，建议将这类检查集成到服务启动阶段。我们内部开发了一个健康检查组件，会在应用启动时自动验证：