强制类型转换几乎无运行时开销，但带来精度截断、溢出静默错误、隐式转换语义反转及可维护性下降等风险。
强制类型转换本身几乎不产生运行时性能开销——它只是告诉编译器“按这个类型解释内存中的位”，不涉及计算或函数调用。真正有代价的，是转换背后隐含的逻辑风险和维护成本。
精度截断与数值失真
从浮点转整数、大整数转小整数时，系统直接丢弃低位或高位字节，不四舍五入、不报错、不提示：
- float f = 9.99f; int i = (int)f; → i 是 9，不是 10
- int x = 257; byte b = (byte)x; → b 是 1（只取低 8 位）
- long l = 0x123456789ABCDEF0L; short s = (short)l; → s 是 -4336（仅保留低 16 位并符号扩展）
溢出导致静默错误
当源值超出目标类型的表示范围，结果由底层二进制截断决定，完全不可预测：
- unsigned int u = 4000000000U; int i = (int)u; → i 可能为负（如 -294967296），但编译通过、运行无异常
- char c = (char)300; → c 是 44（300 % 256），而非报错或抛异常
- 这类错误在测试中极难暴露，常在特定输入下才触发，定位成本高
隐式转换干扰判断逻辑
混合类型比较或赋值时，编译器自动插入隐式转换，可能反转语义：
- size_t pos = 0; int end = -1; while (end >= pos) { ... } → end 被转成很大的正数，循环永不退出
- if (unsigned int u = 5; int i = -10; u > i) → i 转为 unsigned，-10 变成极大正数，条件恒为 false
- 这类问题不报错，但行为与直觉相反，调试时容易忽略类型提升环节
可读性与可维护性下降
频繁嵌套转换（如 (int)(double)(long)x）掩盖真实意图，增加理解负担：
- 后续开发者难以判断：这是为绕过警告？还是修复历史 bug？抑或本就该用更大类型？
- 重构时容易漏掉某处转换，导致类型链断裂
- 静态分析工具（如 Clang -Wconversion、GCC -Wsign-conversion）虽能预警，但若被习惯性忽略，就失去防护意义
