结论：优先使用 int.TryParse 或 double.TryParse 进行数字输入校验，因其性能高、语义清晰、覆盖全面且不依赖异常；int.Parse 因异常开销大、不自动 Trim、不支持浮点等，不适合高频输入验证场景。
直接说结论：用 int.tryparse 或 double.tryparse，别用 int.parse + 异常捕获，也别自己写正则判断数字开头结尾。
为什么不用 int.Parse 做输入检查
它遇到非数字字符串（比如空格、"12a"、null）直接抛 FormatException 或 ArgumentNullException。异常在输入校验这种高频、预期失败的场景里开销大，逻辑也不直观。
常见错误现象：int.Parse("") 崩、int.Parse(" 123 ") 崩（不自动 Trim）、int.Parse("12.3") 崩（哪怕你只想读整数）。
实操建议：
- 永远优先选
TryParse系列，返回bool表示成功与否，输出参数填值 - 如果业务允许带空格，先调
.Trim()再传给TryParse - 别依赖异常流控制——这不是错误，是用户输错了，得安静处理
int.TryParse 和 double.TryParse 怎么选
看你要接受什么格式。整数输入就用 int.TryParse；带小数点、科学计数法（如 "1.5e3"）、负号的，用 double.TryParse 更稳妥。
使用场景差异：
- 表单里“年龄”字段 →
int.TryParse - “价格”或“体重” →
double.TryParse（注意后续精度问题，货币建议用decimal.TryParse） - 用户可能输
"-42"、"+100"→ 两者都支持，但int.TryParse不接受"12.0"
性能影响：两者底层都是无异常解析，速度接近，差别可忽略。
容易被忽略的边界情况
这些不是冷门，而是上线后真实报错最多的几类：
-
null字符串：传给TryParse返回false，安全；但若先做了str.Length > 0判断再调用，就可能 NRE —— 记得先判null - 全空格字符串：
" "，TryParse返回false，但很多人忘了.Trim() - 溢出值：
int.TryParse("3000000000")返回false（超int.MaxValue），不会抛异常，这点比Parse友好 - 文化相关符号：默认按当前线程
CultureInfo解析，"1,234"在某些区域会解析失败；如需严格 US 格式，显式传CultureInfo.InvariantCulture
要不要用正则判断是否为数字
没必要。正则写起来麻烦，还容易漏 case："-0"、"+.5"、"Infinity"（double.TryParse 能认，正则难覆盖）。
典型错误写法：Regex.IsMatch(s, @"^-?\d+$") —— 这连小数点都不支持，更别说科学计数法或前导空格。
实操建议：
- 纯校验需求，
TryParse一步到位，语义清晰、性能好、覆盖全 - 如果还要提取多个数字，再考虑正则；但单字段输入检查，请交给
TryParse - 自定义格式（比如必须两位小数）？那是业务规则，应在
TryParse成功后再额外验证
真正麻烦的从来不是“怎么判断”，而是“判断之后怎么把错误信息准确还给用户”——比如区分“空输入”“格式不对”“超出范围”，这需要你检查 TryParse 返回值的同时，结合原始字符串做二次判断。
