jdbc字段类型不匹配异常本质是java类型与数据库字段语义或驱动映射规则不一致导致的运行时错误，需对齐类型边界、理解驱动行为、避免默认转换。
Java 中 JDBC 字段类型不匹配异常，本质是 Java 类型与数据库字段语义或 JDBC 驱动映射规则不一致导致的运行时错误，不是编译问题，容易在测试或上线后才暴露。关键在于提前对齐类型边界、理解驱动行为、避免依赖默认转换。
确认列名与字段名严格一致
ResultSet 中通过列名取值时，必须和 SQL 查询返回的实际列名完全相同（区分大小写取决于数据库配置）。常见错误是实体类字段叫 username，但 SQL 写的是 name，或数据库字段是 DICT_VALUE（大写），代码里却用 dict_value 小写访问。
- 优先使用列索引（如
rs.getString(2)）临时验证是否列名问题 - 查询时显式指定别名，让 Java 侧名称可控：
SELECT id AS id, user_name AS username FROM t_user - 检查数据库元信息，确认真实字段名：用
rs.getMetaData().getColumnName(i)打印实际列名
对齐数值类型范围与 JDBC 映射规则
不能只看“名字像”，要逐个核对 Java 类型能否无损承载数据库字段的全部取值范围，并符合驱动默认行为。
-
tinyint(1) 不等于 byte：MySQL 默认把它当布尔处理；若存整数 0~100，连接 URL 必须加
?tinyInt1isBit=false -
smallint 推荐用 Integer 接收：JDBC 驱动通常映射为
Integer而非short，强行用short易触发ClassCastException - bigint ↔ long 安全：两者都是 64 位有符号整数，Spring Data JPA、MyBatis 等默认正确支持
-
decimal/numeric 必须用 BigDecimal：金额、精度敏感字段绝不可用
float或double，否则丢失精度
TEXT/CLOB 字段慎用于 WHERE 条件
达梦、Oracle 等数据库中，TEXT 类型字段不能直接与 String 参数做等值比较，JDBC 驱动会严格校验类型，而图形化工具可能做了隐式转换。
- 首选方案：修改表结构，将非富文本字段改为
VARCHAR(1024)或LONG VARCHAR - 临时绕过：SQL 中用函数转类型，如
WHERE CAST(dict_value AS VARCHAR(100)) = ? - 参数侧不强制转换，避免在 Java 层做
String.valueOf(obj)后再传入——驱动仍识别为原始类型
利用 Spring JDBC 的类型转换机制兜底
如果无法修改数据库或实体类，可借助 Spring 的 ConversionService 注册自定义转换器，把原始 ResultSet 值安全转为目标类型。
- 例如：数据库存 JSON 字符串，Java 实体需
User对象，可写Converter<string user></string> - 注册到
ConversionServiceFactoryBean，再注入JdbcTemplate使用的RowMapper - 避免在
RowMapper匿名内部类里硬编码转换逻辑，便于复用和测试
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
