convert.toint32(string) 与 int.parse 行为一致，对 null 或空字符串均抛 formatexception；所谓“宽容”实为混淆了 convert.toint32(object) 重载（对 null 返回 0）。
Convert.ToInt32 为什么空字符串会抛异常，而 int.Parse 不会？
它其实会——Convert.ToInt32 对 null 或空字符串 "" 都直接抛 FormatException，和 int.Parse 行为一致。很多人误以为“Convert 更宽容”，其实是混淆了 Convert.ToInt32(object) 和 Convert.ToInt32(string) 的重载逻辑：前者对 null 返回 0（因为 null 被当作 DBNull.Value 或可空类型处理），后者才严格校验字符串格式。
实操建议：
- 从数据库读值时优先用
Convert.ToInt32(object)，它能安全处理DBNull.Value和null - 解析用户输入或文件内容时，改用
int.TryParse，避免异常开销 - 别依赖
Convert的“容错假象”——它不自动跳过空格或截断小数，Convert.ToInt32("12.9")仍抛异常
DateTime.Parse 和 Convert.ToDateTime 哪个更适合处理不确定格式的日期？
都不适合。两者都依赖当前线程文化（CurrentCulture），遇到 "2023-05-12"、"12/05/2023" 或 "May 12, 2023" 这类混合格式时极易失败或误判。
实操建议：
- 明确格式时用
DateTime.ParseExact或DateTime.TryParseExact，传入精确的format字符串和CultureInfo.InvariantCulture - 接受多种格式时，传入字符串数组：
DateTime.TryParseExact(input, new[] { "yyyy-MM-dd", "dd/MM/yyyy" }, ...) -
Convert.ToDateTime底层调的就是DateTime.Parse，没额外能力，还多一层装箱开销
Convert.ChangeType 为什么泛型 T 为 int 时，传 decimal 值会失败？
因为 Convert.ChangeType(object, Type) 不走隐式转换路径，只支持预定义的“基础类型直转”（如 string→int、double→int），而 decimal→int 被视为“需显式截断”的操作，默认禁止。
实操建议：
- 确认源类型是否在
Convert支持表内：查 MSDN 文档中 “Supported Conversions” 小节，decimal到整数类型仅支持ToInt32等具名方法，不进ChangeType - 绕过方案：先用
Convert.ToDecimal(obj)转成decimal，再用(int)decValue强转（注意溢出） - 若需通用转换，自己封装：对
decimal、long等类型分支处理，别全扔给ChangeType
使用 Convert.ToString 时，数字转字符串为何有时带千位分隔符？
因为重载 Convert.ToString(object, IFormatProvider) 会读取当前线程的 CurrentCulture，而默认文化（如 zh-CN）启用了千位符。即使你传的是 int，只要走的是 object 版本，就触发格式化逻辑。
实操建议：
- 要纯数字字符串（无格式），用
value.ToString()或Convert.ToString(value)（无 provider 参数） - 需要格式化时，显式传
CultureInfo.InvariantCulture，比如Convert.ToString(1234567, CultureInfo.InvariantCulture) - 特别注意
DataRow["col"]这种 object 取值：即使列是 int，Convert.ToString(row["col"])也会按 culture 格式化，应先转具体类型再 ToString
最常被忽略的一点：Convert 类不是类型转换的“万能胶”，它的设计目标是统一处理 object 和数据库/序列化场景中的松散值，而不是替代语言级转换或解析逻辑。越想让它干更多事，越容易掉进文化、空值、精度丢失的坑里。
