Java与数据库字段映射需严格对齐数值范围和语义：tinyint(1)≠byte（需配置tinyInt1isBit=false），smallint→short需ORM支持，bigint↔long安全，decimal→BigDecimal必用；字面量类型、运算提升、ORM显式声明及时间/布尔字段时区与语义均须精准控制。
Java基本类型转换与数据库字段映射的精度对齐，核心在于两点：一是理解Java各基本类型的取值范围和隐式/显式转换规则，二是清楚主流数据库（如MySQL）对应字段类型的语义与JDBC驱动的实际行为。错配常导致数据截断、布尔误判、溢出或运行时异常，不是编译期能发现的问题。
明确Java与数据库字段的数值范围边界
必须逐一对齐，不能只看“名字像”或“字节相同”：
-
tinyint(1) ≠ byte：MySQL中
tinyint(1)常被用作布尔标志，但JDBC默认按tinyInt1isBit=true将其映射为Boolean；若业务上它存的是0~100的整数，就必须在连接URL中显式加?tinyInt1isBit=false，否则读取会抛ClassCastException -
smallint → short？需谨慎：MySQL
smallint是有符号16位（-32768 ~ 32767），Javashort范围一致，但JDBC通常映射为Integer（防溢出设计）。若实体类强行用short接收，需确认ORM是否支持，否则可能报类型不匹配 - bigint ↔ long 是安全的：两者均为64位有符号整数，范围完全一致（-9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807），Spring Data JPA、MyBatis等默认正确映射，无需额外配置
-
decimal/numeric → BigDecimal：金融类字段绝不能用
float或double接收，必须用java.math.BigDecimal。JDBC驱动原生支持，且能保留精度；用double会导致0.1+0.2≠0.3这类问题
处理自动转换陷阱：运算提升与字面量默认类型
Java在表达式中会自动提升操作数类型，但数据库写入/查询时是按字段定义的原始类型处理，二者不一致就容易出错：
- 整数字面量默认是
int，比如写statement.setInt(1, 10000000000)会编译失败——因为10000000000超出int范围，必须写成10000000000L再用setLong - 两个
byte相加结果是int，所以byte a = 100; byte b = 50; byte c = (byte)(a + b);必须强制转回，否则编译报错；同理，ORM中若数据库字段是tinyint，但Java里用byte接收，计算后赋值前也得手动截断 -
float字面量必须带f后缀（如3.14f），否则JDBC认为是double，调用setFloat会报错；而MySQL的float字段实际存储精度有限，不建议用于金额
ORM层的关键控制点
框架不会替你做语义判断，需主动干预类型映射逻辑：
立即学习“Java免费学习笔记（深入）”；
- MyBatis中，在
<resultMap>里明确指定jdbcType和javaType，例如：<result column="status" property="status" jdbcType="TINYINT" javaType="java.lang.Integer"/>，避免依赖驱动默认行为 - JPA/Hibernate中，用
@Column(columnDefinition = "tinyint(1) unsigned")配合Integer字段，比依赖@Convert更直接；若真要映射为布尔，确保数据库该列只存0/1，并加@Column(columnDefinition = "tinyint(1)")+ 实体用Boolean - Spring Boot配置JDBC URL时，对
tinyint统一加tinyInt1isBit=false，再配合代码层用Integer接收，是最稳妥的通用方案
时间与布尔类字段的特殊对齐
这些类型没有直接对应的Java基本类型，但容易被忽略精度语义：
- MySQL
datetime或timestamp应映射为LocalDateTime（非Date），后者已废弃且含时区歧义；若字段含时区信息（如timestamp with time zone），必须用ZonedDateTime或Instant -
bit(1)在MySQL中不是布尔，而是二进制位；JDBC映射为Boolean仅当值为0或1，若存了2或NULL，会抛异常。建议业务层统一用TINYINT(1)+tinyInt1isBit=false+Integer接收，再由Java逻辑判断真假 - 所有时间字段务必检查MySQL服务器时区与JVM时区是否一致，否则
LocalDateTime.now()写入再读出可能差8小时——这不是类型问题，但直接影响精度对齐效果
