java强制转换非语法糖，而是将类型安全责任推给开发者，易致静默失真、运行时崩溃；应改用math.tointexact、parseint等安全替代方案并加强边界校验。
Java 强制转换不是语法糖，而是把类型安全的“责任”直接甩给开发者。它不报错、不警告、不拦截——值越界了变成负数，精度丢了就没了，类型不对等到运行才崩。隐患藏得深，测试不到位，上线就出事。
数值截断：看似简单，实则静默失真
基本类型强制转换（如 (int) doubleValue 或 (byte) 200）不会四舍五入，也不校验范围，只做低位截取或向零舍弃：
-
浮点转整型：
double d = -3.9;→(int)d得-3，不是-4；想四舍五入必须先调Math.round(d)，且注意返回的是long -
整型缩容：
int x = 200;→(byte)x得-56（只取低 8 位，符号位被重解释） -
时间戳误用：
System.currentTimeMillis()是long，直接(int)强转在 2038 年后必然溢出，得到负毫秒值，查询逻辑全乱
类型误判：泛型擦除+JSON默认解析=运行时炸弹
泛型在 JVM 中已擦除，而 JSON 库（如 Jackson/Gson）解析数字默认为 Double 或 Long，不是 Integer。裸写 (Integer)obj 极易触发 ClassCastException：
- Map 中的数字字段，即使前端传的是
"age": 25，Jackson 默认解析为Double，不是Integer -
List<object></object>混存字符串和数字时，(String) list.get(1)编译通过，运行到取值才崩 - 安全做法是先判断再取值：
if (obj instanceof Double) { int v = ((Double) obj).intValue(); }，或封装成NumberUtils.toInt(obj)
溢出边界测试：不能只靠“应该不会超”
真实系统中，ID、计数器、时间戳、金额等都可能突破 int 范围。光靠经验预估不可靠，必须设计边界用例验证：
- 测试
long → int：覆盖Integer.MAX_VALUE + 1、Integer.MIN_VALUE - 1、刚好等于边界值三种情况 - 用
Math.toIntExact()替代裸强转，让溢出变为可捕获的ArithmeticException，便于统一兜底 - 数据库字段是
BIGINT（如 MySQL 主键），读取后若需转int，必须加校验或明确约定业务上限（如 ID ≤ 20 亿） - HTTP 参数或配置项中的数字，应视为不可信输入，强制转换前一律做范围检查
安全替代方案：少写括号，多写校验
真正降低风险的方式，不是更熟练地写 (int)，而是绕开裸强转：
- 数值转换优先用 JDK 内置工具：
Math.toIntExact(long)、Math.floorDiv()、Double.isFinite()配合手动范围判断 - 字符串转数字用
Integer.parseInt(str)或Integer.valueOf(str)，它们会校验格式与范围，非法输入抛NumberFormatException - 泛型集合转换避免整体强转，改用流式处理：
list.stream().map(Number::intValue).collect(Collectors.toList()) - 自定义工具类统一收口，例如
SafeCasts.toInt(Number n)，内部处理null、类型分发、溢出提示
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
