强制转换不是架构组件，高稳定性系统应避免在核心通信层使用；数据入口须类型校验，用泛型反序列化、orm映射、protobuf等保障类型安全，dto/vo/entity转换须经显式、可测、带校验的专用转换器。
Java 强制转换本身不是架构组件，而是一种底层语言操作；在高稳定性系统中，它不应出现在数据传输主链路中。真正关键的是：避免在核心通信层（如序列化、RPC、消息体解析）使用强制类型转换，而是通过类型安全的设计前置拦截风险。
数据传输入口必须做类型校验
外部输入（HTTP 请求参数、MQ 消息体、DB 查询结果）一律视为不可信。不能依赖强制转换兜底：
- 用 Jackson/Gson 的泛型反序列化（如
TypeReference<list>></list>），而非先转Object再强转 - 数据库查询统一使用 MyBatis 的
resultType或 JPA 的实体映射，禁止ResultSet.getObject(i)后手动强转 - RPC 接口定义明确字段类型，Protobuf/Thrift 自动生成类型安全的 Java 类，杜绝运行时转型
领域对象间转换走专用转换器，不裸写强转
不同层之间（如 DTO ↔ VO ↔ Entity）的数据搬运，必须封装为显式、可测试、有日志的转换逻辑：
- 使用 MapStruct 或 ModelMapper，编译期生成类型安全的转换代码，避免
(OrderVO) obj这类脆弱写法 - 自定义转换器中若需数值缩容（如
long→int），必须先校验范围：if (id > Integer.MAX_VALUE || id - 所有转换方法加
@NonNull注解，并配合 Lombok 的@RequiredArgsConstructor防止空指针
泛型与数组场景禁用运行时强转
这两类是 ClassCastException 高发区，且编译器无法预警：
- 不要写
List list = getRawList(); List<user> users = (List<user>) list;</user></user>—— 改用list.stream().map(User.class::cast).toList()或显式遍历校验 - 数组转换仅限继承体系内（如
Object[]→String[]），且必须用Arrays.stream(arr).map(String.class::cast).toArray(String[]::new)替代(String[]) arr - 对第三方 SDK 返回的原始集合，优先包装为不可变视图（
ImmutableList.copyOf(...)），切断误强转路径
监控与告警覆盖隐式强转风险点
即使代码规避了显式强转，JVM 在装箱/拆箱、自动提升等场景仍会触发隐式转换，可能引发静默精度丢失：
- 在关键金融计算模块启用 JVM 参数
-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining审计数值运算路径 - 用字节码插桩（如 Byte Buddy）监控
checkcast指令高频出现的方法，标记为稳定性风险点 - 对
double → int、long → short等窄化操作，统一封装为SafeCasts.toIntExact(double)并记录告警日志
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
