强制类型转换仅截断不四舍五入，且不检查溢出；应先用Math.Round等明确取整，再用checked或toIntExact校验溢出，字符串转数值须经解析→中间类型→目标类型三步。
强制类型转换会直接截断，不是四舍五入
当你用 (int)9.997 这种写法把 double 转成 int，结果是 9，不是 10。C# 和 Java 都一样：强制转换只做截断（truncation），不带任何舍入逻辑。
如果你的接口要求传 int，但上游给的是 double 或 long，直接强转可能悄悄丢掉小数部分或高位数据，尤其在边界值上容易出错。
- 常见错误现象：
Math.PI * 100得到314.15926...，(int)后变成314，而业务其实需要最接近的整数 - 正确做法：先用
Math.Round()、Math.Floor()或Math.Ceiling()明确控制取整行为，再强转 - 注意
Math.Round(double)返回double，而Math.Round(decimal)返回decimal；若目标是int，仍需额外(int)转换
目标类型范围不足时，强制转换不报错但结果溢出
C# 和 Java 的数值强制转换默认不检查溢出。比如把 long.MaxValue（约 9.2×10¹⁸）转成 int，结果是 -1（补码回绕），而不是抛异常。
这在对接外部接口时特别危险——你传了个看似合理的数字，接口却收到一个完全不对的负值，排查起来非常隐蔽。
- 使用场景：调用老接口，参数定义为
int，但你本地计算用了long累加 - 安全做法：对可能越界的值，先用
checked块（C#）或Math.toIntExact()（Java）做显式溢出检查 - C# 示例：
checked { int x = (int)bigValue; }，越界时抛OverflowException - Java 示例：
int x = Math.toIntExact(bigValue);，越界时抛ArithmeticException
接口接收 object 或泛型参数时，别用 (T) 强转原始值
比如某个方法签名是 void PostData，你传 PostData，编译器不会帮你转；如果改成 PostData，看起来没问题，但若 T 实际是 string 或自定义类，这种硬编码强转就彻底失效。
更常见的是误把装箱后的 double 直接 (int) 强转，例如：object o = 3.14; int x = (int)o; —— 这会直接抛 InvalidCastException，因为 object 存的是 double 类型，不能跨类型直接强转。
- 正确路径：先用
Convert.ToInt32(o)（C#）或Integer.parseInt(String.valueOf(o))（Java）做安全解析 - 或者先
o is double d判断类型，再处理 - 避免在泛型方法内部对
T做具体数值类型假设，除非你用where T : struct, IConvertible约束
字符串 → 数值 → 接口类型，三步缺一不可
很多“强制转换”问题其实源头是字符串。比如从 JSON 或配置里读出 "123.45"，想塞进只要 short 的字段，不能直接 (short)"123.45" —— 这语法根本不存在。
必须分三步：字符串解析 → 中间数值类型（如 double 或 decimal）→ 目标窄类型（如 short）。中间这一步决定了精度和容错能力。
- 推荐优先用
decimal解析货币类字符串，避免double的二进制浮点误差 - C#：
short s = (short)Convert.ToDecimal("123.45");，但注意Convert默认四舍五入，不是截断 - Java：
short s = Short.parseShort(String.valueOf(new BigDecimal("123.45").setScale(0, RoundingMode.HALF_UP).intValue()));，太绕？那就拆成两行，别堆在一个表达式里 - 关键点：每一步都要有明确的失败处理，比如
TryParse或try/catch NumberFormatException
强制类型转换本身很简单，真正复杂的是它前面那几步：你怎么拿到这个值、它原本是什么精度、有没有被中间层悄悄改过、以及接口文档里写的“int”到底指 32 位有符号整数，还是只是“一个整数量”的模糊描述。这些地方不确认清楚，光盯着括号里的类型写法，反而最容易翻车。
