Java 严格类型检查靠“立”而非“堵”，通过编译期显式契约（类型声明、泛型约束、重载解析）和运行期真实身份校验（数组存储检查、强制转换验证、反射类型校验）双重保障，辅以高内聚实体类型设计与外部数据安全封装，将隐式 Bug 拦截在最早环节。
Java 的严格数据类型检查不是靠“堵”而是靠“立”——用编译期显式契约 + 运行期真实身份校验，把隐式 Bug 拦在执行前。关键不在禁用转换，而在让错误在最早、最明确的环节暴露出来。
编译期就卡死非法赋值和调用
Java 要求所有变量、参数、返回值必须声明类型（或由 var 安全推导），编译器据此验证每一步操作是否合法：
- 赋值时右侧表达式的静态类型必须是左侧类型的子类型，
String s = "hello"合法，但int i = "123"直接报错，不给机会静默失败 - 方法调用不自动拓宽用于重载解析，
void f(int x)和void f(long x)共存时，传入1L调用后者，传入1只能匹配前者，避免因隐式提升导致意外交互 - 泛型在擦除前完成完整约束检查，
List<String> list = new ArrayList<>(); list.add(42);在编译期就报错，不会等到运行时才出问题
用高内聚实体类型从源头杜绝歧义
实体类字段类型选错，是隐式 Bug 最隐蔽的温床。基本类型和原始包装类混用、浮点数存金额、字符串代状态，都会埋下静默偏差：
- 用
Boolean（而非boolean）表示可为空的业务开关，避免数据库 NULL 反序列化成false导致误判 - 金额字段一律用
BigDecimal，不接受double或float，从类型系统上封死0.1 + 0.2 != 0.3类误差 - 时间点用
Instant，不用Date或long，语义清晰且不可变，规避时区误读 - 状态字段优先用枚举（
OrderStatus.PAID），不用String或Integer，让错别字（如"PAID1"）在编译期就无法通过
运行期守住对象真实类型边界
编译期拦不住全部问题（比如多态容器里的对象），Java 在运行期仍保留关键类型信息做二次校验：
立即学习“Java免费学习笔记（深入）”；
- 数组创建时记录组件类型，
String[] arr = new String[3]; arr[0] = new Integer(1);抛ArrayStoreException，而非静默转型 - 强制转换
(T) obj会检查对象实际类型是否属于目标类型或其子类，失败立即抛ClassCastException，不返回无效引用 - 反射调用前校验类型兼容性，
method.invoke(obj, "wrongType")触发IllegalArgumentException，而不是让逻辑跑偏
关键入口做显式校验与安全封装
来自外部的数据（API、表单、DB 查询结果）默认不可信，不能依赖“它应该是数字”这种假设：
- 所有数值类字段（如订单数量、折扣率）在首个接收节点后立即做
Objects.requireNonNull()+instanceof或NumberUtils.createLong()等安全转换 - 配合
isNaN()、isFinite()检查转换结果，空字符串、带单位字符串（如"42kg"）先trim()再正则过滤，不放行模糊值 - 涉及金额计算统一用
Math.round(value * 100) / 100保留两位小数；条件判断前加!isNaN(x) && isFinite(x) - 批量处理时避免
arr.map(Number)（会把空串转成0），改用arr.map(x => x && !isNaN(x) ? Number(x) : null)
